Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125058
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: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
Date: Mon, 19 Aug 2024 20:44:32 -0400
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F2350730-7DA9-4901-A86C-B7AE58EF4857@newclarity.net>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
To: Derick Rethans <derick@php.net>
From: mike@newclarity.net (Mike Schinkel)

> On Aug 19, 2024, at 1:08 PM, Derick Rethans <derick@php.net> wrote:
>=20
> Hi!
>=20
> Arnaud, Larry, and I have been working on an article describing the=20
> state of generics and collections, and related "experiments".
>=20
> You can find this article on the PHP Foundation's Blog:
> =
https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collection=
s/
>=20
> cheers,
> Derick

Great job on providing so much detail in your blog post.

JMTCW, but I am less of a fan of boil-the-ocean generics and more of a =
fan of focused pragmatic solutions like you proposed with the Collection =
types.  The former can result in really complex to read and understand =
code  whereas the latter =E2=80=94 when done well =E2=80=94 results in =
easier to read and understand code.
=20
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.

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.

--------

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.

If you are going to pursue  type-erasure I recommend introducing a file =
in the root =E2=80=94 call it `.php.config` or similar =E2=80=94 that =
contains a wildcard enabled tree-map of code with attributes settable =
for each file, directory, group of files and/or group of directories =
where one attribute is type-checked or other attributes are reserved for =
future use. This config file should also be able to delegate the =
`.php.config` files found elsewhere, such as config files for each =
package in the vendor directory. It would be much better and easier to =
swap out a few `.php.config` files during CI/CD than to update all =
files.

Additionally PHP could use an environment variable as prescribed by 12 =
Factor apps to identify the root config file. That way a hosting company =
could allow someone to configure their production server to point to =
`.php.production.config` instead of ``.php.development.config`.=20

-Mike

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

This is much like how `Stringable` is just automatically implemented by =
any class that has a `__ToString()` method, but making this automatic =
implementation available to userland. Then these automatically-declared =
interfaces can cover some of the use-cases for generics without the =
complexity of generics.

For example =E2=80=94 to allow you to visualize =E2=80=94 consider a =
`Printable` interface that defines a `print()void` method. If some PHP =
library has a class `Foo` and it has a method with signature =
`print()void` then we could write a function to use it, maybe like so:

---------
interface Printable {
   print($x any)void
}

// The prefix `?` on `Printable` means `$printer` just has to match the =
`Printable` interface's signature
function doSomething($printer ?Printable) {=20
   $printer->print()
}

$foo =3D new Foo();
doSomething($foo);
---------

Something to consider? =20

[1] https://en.wikipedia.org/wiki/Structural_type_system