guilhermebla...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
