Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125093
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] State of Generics and Collections
In-Reply-To: <CAP1Jc12aEY+uy1zT=Q_t4fwE9OZdS1pniDiwA6jO-BBjGRjZpQ@mail.gmail.com>
Date: Wed, 21 Aug 2024 14:24:43 -0400
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D586DA56-D0FE-42CD-A015-EEAD91AA71E8@newclarity.net>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <F2350730-7DA9-4901-A86C-B7AE58EF4857@newclarity.net>
 <CAP1Jc12aEY+uy1zT=Q_t4fwE9OZdS1pniDiwA6jO-BBjGRjZpQ@mail.gmail.com>
To: Arnaud Le Blanc <arnaud.lb@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Aug 20, 2024, at 9:44 AM, Arnaud Le Blanc <arnaud.lb@gmail.com> =
wrote:
>=20
> Hi Mike,
>=20
> On Tue, Aug 20, 2024 at 2:45=E2=80=AFAM Mike Schinkel =
<mike@newclarity.net> wrote:
>> It seems Java-style Generics are viewed as the proper archetype for =
Generics in PHP?  I would challenge the wisdom of taking that road =
considering how different the compilers and runtimes are between the =
Java and PHP.  PHP should seek out solutions that are a perfect fit for =
its nature and not pursue parity with Java.
>=20
>> As PHP is primarily a web development language =E2=80=94 vs. a =
systems language like C or Rust, or an enterprise application language =
like Java or C# =E2=80=94 reducing code complexity for reading and =
understanding is a very important attribute of the language.
>=20
>> PHP is also a unique language and novel solutions benefit a unique =
language. PHP should pursue solutions that result in less complex code =
even if not found in other languages. Your collections idea is novel =E2=80=
=94 which is great =E2=80=94 but there are probably even more novel =
solutions to address other needs vs. going full-on with Java-style =
generics.
>=20
>> Consider if adding type aliases; or augmenting, enhancing, or even =
merging classes, interfaces, and/or traits to address the needs =
Java-style generics would otherwise provide. I would work on some =
examples but I think you are more likely to adopt the features you come =
up with on your own.
>=20
> Part of the appeal for Java/C#/Kotlin-like generics is that they are
> well understood and their usefulness is not to be proven.=20

Yes, they are well understood by programmers who develop in a =
significantly more complex language. So while I acknowledge that appeal, =
I think the complexity provides benefit for most PHP developers.

> Also they fit well with the object-oriented aspect of the language,=20

Even more importantly, PHP is not Java and what works for a compiled and =
strongly typed language does not necessarily work for a interpreted =
language with looser typing and where only one file can be seen by the =
compiler at a time.

> and many PHP projects already use them via PHPStan/Psalm.

As an aside, it is an interesting data point that such as small percent =
of PHP developers actually use those tools.=20

Could it be because of their complexity? I cannot say for certain that =
is why, but it surely is a factor to ponder.

> More experimental alternatives would be more risky.

Fair point

> I would be interested to see suggestions or examples, however.

Two examples were already shown and/or mentioned: the collections class =
and automatic interface implementation based on structural typing. =20

I am sure they are more, and if I am able to identify any as the topic =
is discussed I will bring them up.

>> As for type-erasure, I am on the fence, but I find the proposed "how" =
problematic.
>> I can see wanting some code to be type-checked and other code not, =
but I think more often developers would want code type-checked during =
development and testing but not for staging or production. And if the =
switch for that behavior is in every file that means modifying every =
file during deployment. IMO that is just a non-starter.
>=20
> The reason for this "how" is that type checking is also coercing, so
> disabling it "from the outside" may break a program that's not
> designed for that.

AFAIK if you are using type checking then the code is never correct if =
the types do not match, the errors just may go unreported. Thus I do not =
see how the code that uses code with types could not be designed for =
code with types; disabling if from the outside does not change that.=20

Disabling type checking is not like changing the syntax that is allowed =
by strict mode, AFAIK.

> type checking is also coercing


However, I do not understand your claim here. Is there some form of =
typing that would modify code behavior if the types were erased? Would =
allowing that even make sense? Can you give an example of this?

> That's why this is something that should be enabled
> on a per-file basis, and can probably not be switched on/off depending
> on the environment.

I reserve my opinion on this awaiting your example(s).

>> P.S. Also consider offering the ability for a function or class =
method to "type" a parameter or variable based on an interface and then =
allow values that satisfy that interface structurally[1] but not =
necessarily require the class to explicitly implement the interface.
>=20
> Unfortunately, I believe that structural types would be very expensive
> to implement at runtime. Static analysers could support this, however
> (PHPStan/Psalm support some structural types already).

But would it really be too expensive? Has anyone ever pursued =
considering it, or just dismissed it summarily? Seems to me it could =
handled rather inexpensively with bitmaps.

-Mike