On Tue, Aug 20, 2024, at 03:53, Bob Weinand wrote:
> 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.
>
I generally follow the philosophy:
1. get it working
2. get it working well
3. get it working fast
And inference seems like a type (2) task. In other words, I think people would
be fine with generics, even if they had to type it out every single time. At
least for a start. From there, you'd have multiple people able to tackle the
inference part, proposing RFCs to make it happen, etc. vs. now where basically
only one person on the planet can attempt to tackle a very complex problem that
doesn't exist yet. That isn't to say it isn't useful research, because you want
to write things in such a way that you can implement inference when you get to
(2), but an actual implementation shouldn't be sought out yet, just
understanding the problem and solution space is likely enough to do (1) while
taking into account (2) -- such as choosing algorithms, op-codes, data
structures, etc.
For a feature like this, perfect is very much the enemy of good.
> "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.)
>
Why doesn't it make sense?
interface Id<T> {
public T $id {
get => $this->id; // pretty sure this is the wrong syntax?
}
public function getId(): T;
public function setId(T $id): void;
}
class StringId implements Id<string> { /* ... */ }
class IntId implements Id<int> { /* ... */ }
For codebases (like the one I work with every day) identifiers may be a string
or int and right now, that interface can't exist.
> 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
>
>
>
— Rob
