Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124140
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <e867bbca-38c4-4523-916d-07e86bea94c9@app.fastmail.com>
In-Reply-To: <FD75AB78-4CF1-457B-8BFD-BE9F7AF723A9@miles.systems>
References: <07A8534A-1B45-4F15-A78B-AA7DDF92B8B6@koalephant.com>
 <5BA404A4-7281-475F-A1F6-D1252ABB059D@miles.systems>
 <a69a759f-f185-42ff-b769-1f85beab673b@app.fastmail.com>
 <FD75AB78-4CF1-457B-8BFD-BE9F7AF723A9@miles.systems>
Date: Mon, 01 Jul 2024 13:14:41 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

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 system =
in Typescript is Turing Complete (https://github.com/microsoft/TypeScrip=
t/issues/14833) and php barely has a type system. It doesn=E2=80=99t eve=
n have consistent type checking, for that matter (properties are checked=
 differently than arguments which are checked differently than construct=
or arguments =E2=80=94 and the fact they agree with each other at all, i=
s interesting, because they don=E2=80=99t arrive at the same conclusions=
 in the same way. I=E2=80=99ve been dealing with subtle bugs here for we=
eks on an unannounced RFC implementation) and this is why generics is a =
can of worms: implementing it would essentially force a rewrite of the t=
ype system into a proper type system.
>>=20
>> In my honest opinion, before we can even have this type of conversati=
on, 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 curren=
tly am). The pattern matching RFC was proposed as though it would be wri=
tten one way, people have thrown out ideas of different syntax, but I do=
n=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 syntax so future RF=
Cs 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 happy=
 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 good=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=98he=
llo=E2=80=99 ];
>
>
> That would allow us to move into an implementation discussion, which i=
s=20
> also absolutely needed.=20
>
> Best,=20
> Richard Miles

As Stephen already said, we have this already.  It's spelled like this:

class A {
  public function __construct(public string $a) {}
}

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,
  ) {}
}

If you know the keys at code 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*.  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 ap=
plication from the PHP 3 days is still doing that, it's past time to upg=
rade it.

So new language features to make "misuse arrays as objects" easier are a=
ctively counter-productive.

A Dict / Hashmap is appropriate when you do *not* know the keys in advan=
ce, and thus cannot use a pre-defined object for it.  There are plenty o=
f use cases for that, but in that case, all you need type-wise is the ke=
y type and value type, because all entries should be of the same type (g=
ive or take inheritance).  Mixing in random other types... is wrong.  Th=
at's the whole reason why people keep talking about collections/typed ar=
rays/generics.

So the "array interface" syntax you keep posting is actively counter-pro=
ductive.

--Larry Garfield