On 20.8.2024 03:31:05, Larry Garfield wrote:
On Mon, Aug 19, 2024, at 5:16 PM, Bob Weinand wrote:Regarding the Collections PR, I personally really don't like it: • It implements something which would be trivial if we had reified generics. If this ever gets merged, and generics happen later, it would be probably outdated and quirkiness the language has to carry around. • It's not powerful. But rather a quite limited implementation. No overrides of the built-in methods possible. No custom operations ("I want a dict where a specific property on the key is the actual unique key", "I want a custom callback be executed for each modification"). It's okay as a PoC, but far from a complete enough implementation.I think we weren't that clear on that section, then. The intent is that dedicated collection classes are, well, classes. They can contain additional methods, and probably can override the parent methods; though the latter may have some trickiness if trying to access the internal data structure, which may or may not look array-ish. (That's why it's just a PoC and we're asking for feedback if it's worth trying to investigate further.)
I assumed so, as said "okay as a PoC" :-)
• It's a very specialized structure/syntax, not extensible for userland at all. Some functionality like generic traits, where you'd actually monomorphize the contained methods would be much more flexible. E.g. class Articles { use Sequence<Article>; }. Much less specialized syntax, much more extensible. And generic traits would be doable, regardless of the rest of the generics investigation. In fact, generic traits (essentially statically replacing the generic arguments at link-time) would be an useful feature which would remain useful even if we had fully reified generics. I recognize that some functionality will need support of internal zend_object_handlers. But that's not a blocker, we might provide some default internal traits with PHP, enabling the internal class handlers. So to summarize, I would not continue on that path, but really invest into monomorphizable generic traits instead.Interesting. I have no idea why Arnaud has mainly been investigating reified generics rather than monomorphized, but a monomorphized trait has potential, I suppose. That naturally leads to the question of whether monomorphized interfaces would be possible, and I have no idea there. (I still hold out hope that Levi will take another swing at interface-default-methods.) Though this still wouldn't be a path to full generics, as you couldn't declare the inner type of an object at creation time, only code time. Still, it sounds like an area worth considering. --Larry Garfield
Nikita did the investigation into monomorphized generics a long time ago (https://github.com/PHPGenerics/php-generics-rfc/issues/44). So it was mostly concluded that reified generics would be the way to go. The primary issue Arnauld is currently investigating, is propagation of generic information via runtime behaviour, inference etc.
It would be solving large amounts of problems if you'd have to fully specify the specific instance of a generic every time you instantiate one. But PHP is at heart a dynamic language where typing is generally opt-in (also when constructing new objects of generic classes for example). And we want to avoid "new List<Entry<Foo<Something>, WeakReference<GodObject>>>()"-style nesting where not necessary.
"Monomorphization of interfaces" does not really make a lot of sense as a concept. Ultimately in an interface, all you do is providing information for classes to type check against, which happens at link time, once. (Unless you mean interface-default-methods, but that would just be an implicitly implemented trait implementation wise, really.)
But sure, generic interfaces and monomorphized generic traits are perfectly implementable today. In fact, I'd definitely suggest we'd start out by implementing these, orthogonally from actual class generics.
Bob
