Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124152 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 4F52E1ADA79 for ; Mon, 1 Jul 2024 17:09:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719853862; bh=/9UDCXTnByCEqgv7mura+fHrAUsR55X41s0lvSvquYo=; h=In-Reply-To:References:Date:From:To:Subject:From; b=gRjwJ/ImnWoy+EZlLWaRWbVTPR25IIFprXm/iP3Tk6lKNMqD2RsTlePWKog+Ag6Wj +M9l41HQml5HAD38swMExEfE9U/ISF/m9n+g4yuc2iqd5y6huwoMt5aI7K4qyqFujP fMVSaPOl/uq7aR+vqmAw+PPBPqGy6L36dAlu+u4rLuVKokxVryWp1stFNwIeH+LqPw kxgnDP4Z5bKCVPrJr18pF7/H7G19aV+6o4P/haakMVx4G5dKwDLOiSahAZcTk1uNk6 C7zHK9tv78E3bwlVrCdVfnylUkyL1ixLChfYhR19nPBlVVHzCLdpPQV1XOc6nUHLo5 pfuwPQoV2sWYw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3CF0C180B3D for ; Mon, 1 Jul 2024 17:10:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from wfout2-smtp.messagingengine.com (wfout2-smtp.messagingengine.com [64.147.123.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Jul 2024 17:10:57 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.west.internal (Postfix) with ESMTP id 229A81C000D0 for ; Mon, 1 Jul 2024 13:09:36 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Mon, 01 Jul 2024 13:09:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1719853775; x=1719940175; bh=J8l9NbKN4d G8YUH7roJrYsUyxzEQ2cJaf8OZtmo7TC8=; b=Z3g33cQauf/iBhYVqAP9F0bqm8 s2WLuR39/2TsspAxlq3hf+4+TnZtSk2It4V2JY3hNnuW3JE5iF69P9p4BuMVcTjR Lf63Qzgl989PxOz1+nXWiyH7oJU5+9k8DuXNgiWUbb2UzK0A8CY2acIhIvPVenx8 V7FEiFi36q9VMeMxSu7mMgAzol7Gc5GaBsVG1cw2C2F+RDngfUE6ek1pKy6YKx0O 3kt+MPC1DDod44xDcPxASomKw3yie5jssNtstk+pKzCOASgxj0q5kwdncnU2lfzF brRO0Ty8qxLQu0wae1FBkg1W31YhwzukL1cazAxF5DoZFAFSsjVCviEYzhEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1719853775; x=1719940175; bh=J8l9NbKN4dG8YUH7roJrYsUyxzEQ 2cJaf8OZtmo7TC8=; b=pWHomFkyFsEG9TebBzwYo0l3N1rQF70z/14reDyyIPk6 bkHx/H1f1aRirBb0GoocmFWYROHiOerLggj/JnOFT9maYxmPH1dXGXZKoRwVpJG6 kla78FFRB6t+AdebOs2RJCJp1B7+mwFtMCzQzQkBnsVj3aO4+qMdEVQsmv4v3wI8 fn389Ojpc9ICrnZN47I1h4aHD4unwBfkyoYofzUpoQM+LxuO3+NRplv4qeLYs1L3 pOhdAx93p1kM3zIrsKk4RLJmirvLm4vx8xCV4KhXHrFCdDuHJ/L1atxENH6ZZNbq sSDTTc3cuB9YkNJgbQIBlsKu5o0WIzjCvj1m4kC5oQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudefgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothht lhgvugdrtghouggvsheqnecuggftrfgrthhtvghrnhepgedvtedtuedvfffgheffjeetvd evtdehjedvhedvieefffduhfevuefhfefhgeffnecuffhomhgrihhnpehgihhthhhusgdr tghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5035115A0093; Mon, 1 Jul 2024 13:09:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <83185115-8590-4164-934d-c14f149982c6@app.fastmail.com> In-Reply-To: References: <07A8534A-1B45-4F15-A78B-AA7DDF92B8B6@koalephant.com> <5BA404A4-7281-475F-A1F6-D1252ABB059D@miles.systems> Date: Mon, 01 Jul 2024 19:09:15 +0200 To: internals@lists.php.net Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays Content-Type: multipart/alternative; boundary=d086f49956df4c9c8d1054f87d190aee From: rob@bottled.codes ("Rob Landers") --d086f49956df4c9c8d1054f87d190aee Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2024, at 15:14, Larry Garfield wrote: > On Mon, Jul 1, 2024, at 12:21 PM, Richard Miles wrote: > > Howdy Rob, > > > >>> I appreciate your feedback, and I think it=E2=80=99s valid. I try = to compare my expectations to what is possible in typescript. > >>=20 > >> I feel like Typescript is the wrong model to follow. The type syste= m in Typescript is Turing Complete (https://github.com/microsoft/TypeScr= ipt/issues/14833) and php barely has a type system. It doesn=E2=80=99t e= ven have consistent type checking, for that matter (properties are check= ed differently than arguments which are checked differently than constru= ctor arguments =E2=80=94 and the fact they agree with each other at all,= is interesting, because they don=E2=80=99t arrive at the same conclusio= ns in the same way. I=E2=80=99ve been dealing with subtle bugs here for = weeks on an unannounced RFC implementation) and this is why generics is = a can of worms: implementing it would essentially force a rewrite of the= type system into a proper type system. > >>=20 > >> In my honest opinion, before we can even have this type of conversa= tion, we need to have an RFC about the syntax (there may already be one,= I haven=E2=80=99t checked =E2=80=94 and internet is spotty where I curr= ently am). The pattern matching RFC was proposed as though it would be w= ritten one way, people have thrown out ideas of different syntax, but I = don=E2=80=99t think there is an =E2=80=9Cofficial=E2=80=9D syntax. A goo= d starting point may be to simply propose an RFC about syntax so future = RFCs can be consistent.=20 > >>=20 > >> =E2=80=94 Rob > > > > I actually did not know it was turning complete, very interesting!=20 > > While it is easy for anyone to say, =E2=80=98we're not even close to=20 > > typescript,=E2=80=99=20 > > that=E2=80=99s precisely what brings me to the table. I would be hap= py with us=20 > > just voting on syntax. It seems like past RFC=E2=80=99s only=20 > > ever got hung up on generics (wrongfully?). I want to work on=20 > > implementing generics, too, after this. I feel this is probably a go= od=20 > > stepping stone.=20 > > > > A vote would solidify the following: > > > > > > interface iArrayA ['a' =3D> string ] > > interface iArrayB extends iArrayA ['b' =3D> string, 'c' =3D> ?string= , =E2=80=98d=E2=80=99=20 > > =3D> SomeClass, =E2=80=98e=E2=80=99=3D> iArrayA, =E2=80=98f=E2=80=99= =3D> mixed ] > > $array =3D (iArrayA &| iArrayB) [ =E2=80=98a=E2=80=99 =3D> =E2=80=98= hello=E2=80=99 ]; > > > > > > That would allow us to move into an implementation discussion, which= is=20 > > also absolutely needed.=20 > > > > Best,=20 > > Richard Miles >=20 > As Stephen already said, we have this already. It's spelled like this: >=20 > class A { > public function __construct(public string $a) {} > } >=20 > class B extends A { > public function __construct( > public string $a,=20 > public string $b,=20 > public ?string $c, > public SomeClass $d, > public A $e, > mixed $f, > ) {} > } >=20 > If you know the keys at code time, use a class, not an array. Full st= op, period, end of story. Using an array as a record object in PHP >=3D= 7 *is wrong*. It's slower, more memory-intensive, less ergonomic, hard= er to debug, harder to statically analyze, harder to learn, harder to us= e. If you're still doing that, it's past time to stop. If your legacy = application from the PHP 3 days is still doing that, it's past time to u= pgrade it. >=20 > So new language features to make "misuse arrays as objects" easier are= actively counter-productive. >=20 > A Dict / Hashmap is appropriate when you do *not* know the keys in adv= ance, and thus cannot use a pre-defined object for it. There are plenty= of use cases for that, but in that case, all you need type-wise is the = key type and value type, because all entries should be of the same type = (give or take inheritance). Mixing in random other types... is wrong. = That's the whole reason why people keep talking about collections/typed = arrays/generics. >=20 > So the "array interface" syntax you keep posting is actively counter-p= roductive. >=20 > --Larry Garfield >=20 No offense, but this whole reply seems pretty counter-productive. =E2=80= =9CJust use objects=E2=80=9D might be a valid use-case for you, but that= isn=E2=80=99t true for everyone. There are a number of uses for arrays (values vs references, cow memory = efficiency, spoed, flexibility, etc) over objects, not to mention all th= e legacy code out there that people won=E2=80=99t seem to pay to rewrite= =E2=80=A6 =E2=80=94 Rob --d086f49956df4c9c8d1054f87d190aee Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Mon, Jul 1, 2024, at 15:14, Larry Garfield wrote:
<= /div>
On Mon, Jul 1, = 2024, at 12:21 PM, Richard Miles wrote:
> Howdy Rob,
>
>>> I appreciate your feedback, = and I think it=E2=80=99s valid. I try to compare my expectations to what= is possible in typescript.
>> 
&= gt;> I feel like Typescript is the wrong model to follow. The type sy= stem in Typescript is Turing Complete (https://github.com/microsoft/TypeScript/= issues/14833) and php barely has a type system. It doesn=E2=80=99t e= ven have consistent type checking, for that matter (properties are check= ed differently than arguments which are checked differently than constru= ctor arguments =E2=80=94 and the fact they agree with each other at all,= is interesting, because they don=E2=80=99t arrive at the same conclusio= ns in the same way. I=E2=80=99ve been dealing with subtle bugs here for = weeks on an unannounced RFC implementation) and this is why generics is = a can of worms: implementing it would essentially force a rewrite of the= type system into a proper type system.
>> 
=
>> In my honest opinion, before we can even have this t= ype of conversation, we need to have an RFC about the syntax (there may = already be one, I haven=E2=80=99t checked =E2=80=94 and internet is spot= ty where I currently am). The pattern matching RFC was proposed as thoug= h it would be written one way, people have thrown out ideas of different= syntax, but I don=E2=80=99t think there is an =E2=80=9Cofficial=E2=80=9D= syntax. A good starting point may be to simply propose an RFC about syn= tax so future RFCs can be consistent. 
>> =
>> =E2=80=94 Rob
>
&= gt; I actually did not know it was turning complete, very interesting!&n= bsp;
> While it is easy for anyone to say, =E2=80=98we'= re not even close to 
> typescript,=E2=80=99 =
> that=E2=80=99s precisely what brings me to the table= . I would be happy with us 
> just voting on synta= x. It seems like past RFC=E2=80=99s only 
> ever g= ot hung up on generics (wrongfully?). I want to work on 
<= div>> implementing generics, too, after this. I feel this is probably= a good 
> stepping stone. 
>= ;
> A vote would solidify the following:
= >
>
> interface iArrayA ['a' =3D>= ; string ]
> interface iArrayB extends iArrayA ['b' =3D= > string, 'c' =3D> ?string, =E2=80=98d=E2=80=99 
> =3D>  SomeClass, =E2=80=98e=E2=80=99=3D>  iArrayA= , =E2=80=98f=E2=80=99 =3D> mixed ]
> $array =3D (iAr= rayA &| iArrayB) [ =E2=80=98a=E2=80=99 =3D> =E2=80=98hello=E2=80=99= ];
>
>
> That would = allow us to move into an implementation discussion, which is 
> also absolutely needed. 
>
=
> Best, 
> Richard Miles
As Stephen already said, we have this already.  It's sp= elled like this:

class A {
&n= bsp; public function __construct(public string $a) {}
}

class B extends A {
  publ= ic function __construct(
    public string = $a, 
    public string $b, 
    public ?string $c,
  = ;  public SomeClass $d,
    public A $= e,
    mixed $f,
  ) {}<= br>
}

If you know the keys at cod= e time, use a class, not an array.  Full stop, period, end of story= .  Using an array as a record object in PHP >=3D 7 *is wrong*.&n= bsp; It's slower, more memory-intensive, less ergonomic, harder to debug= , harder to statically analyze, harder to learn, harder to use.  If= you're still doing that, it's past time to stop.  If your legacy a= pplication from the PHP 3 days is still doing that, it's past time to up= grade it.

So new language features to make = "misuse arrays as objects" easier are actively counter-productive.

A Dict / Hashmap is appropriate when you do *not= * know the keys in advance, and thus cannot use a pre-defined object for= it.  There are plenty of use cases for that, but in that case, all= you need type-wise is the key type and value type, because all entries = should be of the same type (give or take inheritance).  Mixing in r= andom other types... is wrong.  That's the whole reason why people = keep talking about collections/typed arrays/generics.

=
So the "array interface" syntax you keep posting is actively = counter-productive.

--Larry Garfield


No offense, but this = whole reply seems pretty counter-productive. =E2=80=9CJust use objects=E2= =80=9D might be a valid use-case for you, but that isn=E2=80=99t true fo= r everyone.

There are a number of uses for = arrays (values vs references, cow memory efficiency, spoed, flexibility,= etc) over objects, not to mention all the legacy code out there that pe= ople won=E2=80=99t seem to pay to rewrite=E2=80=A6

<= div id=3D"sig121229152">=E2=80=94 Rob
--d086f49956df4c9c8d1054f87d190aee--