> Am 4.6.2016 um 16:17 schrieb Christoph Becker <cmbecke...@gmx.de>: > > 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).
Even if we introduce type aliases, the aliases will still have to contain unions by then. (And then it’d be weird if you could use them in aliases decls but not inline … huh?) Also, the interfaces are _locally_ handled the same (i.e. in the structure passing it forward), but in the big image they are not. >> 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. For which you then need an adapter for each and every combination of interface (power set without empty set; 2^n - 1 - 15 adapter classes for 4 interfaces). That’s not a practical solution here. Bob > -- > Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
