On 04.06.2016 at 14:15, Bob Weinand wrote: >> Am 04.06.2016 um 13:45 schrieb Niklas Keller <m...@kelunik.com>: >> >> For Aerys\Host it could also be solved with an interface that just doesn't >> have any methods. With the disadvantage of callable not being in the same >> signature anymore. > > Also, it requires you to inverse responsibilities. You'd have to specify a > common super-interface on every single fundamentally unrelated interface > (which are only indirectly related by the fact that they receive common > handling in a single place). That's a clear anti-pattern.
I agree, but I can't see why using a union type would be much better, as you would still bundle up a bunch of "fundamentally unrelated interface"s in a single (union) type. While I see a small benefit in the explicit notion of the union type in the function's signature, that would completely vanish if we introduce some kind of type aliases later (as already noted in the "future scope" section as potential improvement). > Additionally, this is only possible if you are actually in control on these > classes and can change them. If you pull them from a library, no chance. In which case it might make sense anyway to use adapters. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
