Re: [RFC] [PRE-VOTE] Union types

On 04.06.2016 at 14:15, Bob Weinand wrote: >> Am 04.06.2016 um 13:45 schrieb Niklas Keller <me@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