Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125070
Precedence: bulk
MIME-Version: 1.0
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net> <F2350730-7DA9-4901-A86C-B7AE58EF4857@newclarity.net>
In-Reply-To: <F2350730-7DA9-4901-A86C-B7AE58EF4857@newclarity.net>
Date: Tue, 20 Aug 2024 15:44:41 +0200
Message-ID: <CAP1Jc12aEY+uy1zT=Q_t4fwE9OZdS1pniDiwA6jO-BBjGRjZpQ@mail.gmail.com>
Subject: Re: [PHP-DEV] State of Generics and Collections
To: Mike Schinkel <mike@newclarity.net>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Mike,

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 Gener=
ics in PHP?  I would challenge the wisdom of taking that road considering h=
ow 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 pur=
sue parity with Java.

> As PHP is primarily a web development language =E2=80=94 vs. a systems la=
nguage 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 ver=
y important attribute of the language.

> PHP is also a unique language and novel solutions benefit a unique langua=
ge. PHP should pursue solutions that result in less complex code even if no=
t 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 addr=
ess other needs vs. going full-on with Java-style generics.

> Consider if adding type aliases; or augmenting, enhancing, or even mergin=
g classes, interfaces, and/or traits to address the needs Java-style generi=
cs would otherwise provide. I would work on some examples but I think you a=
re more likely to adopt the features you come up with on your own.

Part of the appeal for Java/C#/Kotlin-like generics is that they are
well understood and their usefulness is not to be proven. Also they
fit well with the object-oriented aspect of the language, and many PHP
projects already use them via PHPStan/Psalm. More experimental
alternatives would be more risky. I would be interested to see
suggestions or examples, however.

> As for type-erasure, I am on the fence, but I find the proposed "how" pro=
blematic.
> 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.

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. 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.

> 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 th=
e class to explicitly implement the interface.

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).

Best Regards,
Arnaud