Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: Bob Weinand <bobwei9@hotmail.com>, Niklas Keller <me@kelunik.com>
References: <BLU437-SMTP785CB095BE08FBC1CC2FAFE2580@phx.gbl>
 <0A.C5.62101.1C860575@pb1.pair.com>
 <a58caf44-dae1-c544-804f-089360243607@gmail.com>
 <BLU436-SMTP187447B1819635CD2E6962E2580@phx.gbl>
 <68b821ac-d71f-4be5-8dca-ae94db332630@gmail.com>
 <BLU436-SMTP208CF2757B67BA061C8EEADE2580@phx.gbl>
 <20160603101659.D466A1A81FC5@dd1730.kasserver.com>
 <6d448fd8-8fda-d795-accb-6b96cd128ccd@gmail.com>
 <BLU436-SMTP1304B21C2B677B1455A9E54E2590@phx.gbl>
 <652fdc5a-a164-2054-ed61-305a2b72330a@gmail.com>
 <BLU436-SMTP97AAE59E20D9AF3436B732E2590@phx.gbl>
 <c2609544-31cb-d699-4352-6e5497ee1d9b@gmail.com>
 <20160603142421.346B81A81725@dd1730.kasserver.com>
 <9814df22-9854-616b-bf02-d0742efefaff@gmail.com>
 <20160603145857.8413F1A8323C@dd1730.kasserver.com>
 <1fb072b3-9b9e-1dfd-6b39-7875587b6c7d@seld.be>
 <5751B50F.2090003@garfieldtech.com>
 <BLU436-SMTP130242DCE403FFB527B7F3BE2590@phx.gbl>
 <CANUQDCgu9sgOpSsoukj_PpDk7PPV0vnMuq3wwUj-okJwZuT9Qw@mail.gmail.com>
 <BLU436-SMTP8648B1BCE09FBF02700F20E25A0@phx.gbl>
Cc: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
Message-ID: <9c759795-a702-4f02-7eba-f1bd6fcb4ec2@gmx.de>
Date: Sat, 4 Jun 2016 16:17:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP8648B1BCE09FBF02700F20E25A0@phx.gbl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types
From: cmbecker69@gmx.de (Christoph Becker)

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