On 4/19/2016 11:41 AM, Zeev Suraski wrote:
> It could actually implement all of them - the two parents, and the child.
> That sounds like a pretty good, explicit way that requires no introduction of
> any new syntax, concepts or engine complexity in order to do what you're
> describing. This works fine:
>
> interface foo { function foo(); }
> interface bar { function bar(); }
> interface baz extends foo,bar {}
>
> class impl implements foo, bar, baz {
> function foo(){}
> function bar(){}
> }
>
> function sth(baz $b){}
>
`class impl implements baz {}` is actually already enough here because
`baz` extends `foo` and `bar`. This is the only way to solve such
situations right now but it does not help with primitive types. :(
> One thing we could consider is adding some intelligence for these cases, and
> for interfaces that only extend other interfaces (without adding new
> signatures) - a class would be considered to implement that interface if it
> implements all of the 'parent' interfaces that the child interface extends:
>
> class impl implements foo, bar {
> function foo(){}
> function bar(){}
> }
>
> function sth(baz $b){} <-- would work, as impl implements both foo and bar,
> and baz does nothing but extending those.
>
> I'm not sure that's necessary, and believe the current mechanisms and syntax
> satisfy these use cases already, but it's probably a possibility.
>
That sounds like runtime checked duck typing. This actually makes the
type system less strict and might have horrific side effects and that is
exactly the opposite of what union/intersection types are meant for:
preventing this. Above code is the same as:
function sth($b) {
$b->foo();
$b->bar();
}
It will definitely fail if something else is passed in but if it is
`foo`, `bar`, or `baz` everything is fine. The problem is that any
object that satisfies the implementation of the methods `foo` and `bar`
would ultimately fulfill the contract here.
function sth(foo&bar $b) {}
This is a different situation because now we know that it is something
that actually implements exactly those two interfaces. Including
possible additional constraints like argument and return type hints.
There might even be a documentation shipped together with them that the
implementer should take care of honoring. The intersection type hint is
much stricter in such cases.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
