Re: State of Generics and Collections

Hi Mike, On Tue, Aug 20, 2024 at 2:45 AM 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. > 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