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