> On Aug 20, 2024, at 9:44 AM, Arnaud Le Blanc <arnaud...@gmail.com> wrote: > > 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.
Yes, they are well understood by programmers who develop in a significantly more complex language. So while I acknowledge that appeal, I think the complexity provides benefit for most PHP developers. > Also they fit well with the object-oriented aspect of the language, Even more importantly, PHP is not Java and what works for a compiled and strongly typed language does not necessarily work for a interpreted language with looser typing and where only one file can be seen by the compiler at a time. > and many PHP projects already use them via PHPStan/Psalm. As an aside, it is an interesting data point that such as small percent of PHP developers actually use those tools. Could it be because of their complexity? I cannot say for certain that is why, but it surely is a factor to ponder. > More experimental alternatives would be more risky. Fair point > I would be interested to see suggestions or examples, however. Two examples were already shown and/or mentioned: the collections class and automatic interface implementation based on structural typing. I am sure they are more, and if I am able to identify any as the topic is discussed I will bring them up. >> 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. AFAIK if you are using type checking then the code is never correct if the types do not match, the errors just may go unreported. Thus I do not see how the code that uses code with types could not be designed for code with types; disabling if from the outside does not change that. Disabling type checking is not like changing the syntax that is allowed by strict mode, AFAIK. > type checking is also coercing However, I do not understand your claim here. Is there some form of typing that would modify code behavior if the types were erased? Would allowing that even make sense? Can you give an example of this? > 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. I reserve my opinion on this awaiting your example(s). >> 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). But would it really be too expensive? Has anyone ever pursued considering it, or just dismissed it summarily? Seems to me it could handled rather inexpensively with bitmaps. -Mike
