Re: [RFC:generics]

guilhermeblanco@gmail.com wrote on 21/04/2016 16:25:

I understand others mentioned we could create a new interface that wraps the other two interfaces, but that still doesn't solve the problem where I want to extend a class AND also implement a specific interface.

I covered this case in my previous mail: you can create an abstract class that extends a concrete class and adds an interface to it, and the extra methods are implicitly added as abstract for descendants to implement: // This could be somewhere else in code you don't want to touch class Foo { public function doStuff() { /* ... */ } } interface Bar { public function neededAction(); } // Wherever you need to use the intersection Foo & Bar abstract class FooBar extends Foo implements Bar {} class Foo<T instanceof FooBar> { /* can rely on both T#doStuff and T#neededAction existing */ } // The implementation of the intersection must be in our control, to use "FooBar" rather than "Foo" as a base // This is also true of extending interfaces, since PHP doesn't do duck-typing of interfaces class FooBarImplementation extends FooBar { public function neededAction() { /* ... */ } }

What happens if the initial one get approved but it is too late to propose the subsequent one? Then PHP 7.1 would be released with a partial implementation and not fully featured as it should.

No other part of the language allows such type algebra, so a generics implementation that doesn't allow it wouldn't feel "incomplete" to anyone who wasn't aware of the discussion. Do you consider the typehints PHP has had for over a decade to be "a partial implementation" because they don't include this feature? I'm assuming that if generics passed, and type algebra passed, then generics-with-type-algebra would go through on the nod and make it to the same version. Regards, -- Rowan Collins [IMSoP]