Hi Mike,
On Tue, Aug 20, 2024 at 2:45 AM Mike Schinkel <[email protected]> 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.
> As PHP is primarily a web development language — vs. a systems language like C or Rust, or an
> enterprise application language like Java or C# — 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 — which is great — but there are probably even more novel solutions to address
> other needs vs. going full-on with Java-style generics.
> 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.
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" 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.
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 the 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