Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93767
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.88 as permitted sender)
Message-ID: <BLU437-SMTP63441365967EDE0F927E64E25A0@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <9c759795-a702-4f02-7eba-f1bd6fcb4ec2@gmx.de>
Date: Sat, 4 Jun 2016 16:37:38 +0200
CC: Keller Niklas <me@kelunik.com>,
 Larry Garfield <larry@garfieldtech.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
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>
 <9c759795-a702-4f02-7eba-f1bd6fcb4ec2@gmx.de>
To: Christoph Becker <cmbecker69@gmx.de>
Subject: Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types
From: bobwei9@hotmail.com (Bob Weinand)


> Am 4.6.2016 um 16:17 schrieb Christoph Becker <cmbecker69@gmx.de>:
>=20
> On 04.06.2016 at 14:15, Bob Weinand wrote:
>=20
>>> Am 04.06.2016 um 13:45 schrieb Niklas Keller <me@kelunik.com>:
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> 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=E2=80=99d be weird if you could use =
them in aliases decls but not inline =E2=80=A6 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.
>=20
> 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=E2=80=99s not a practical solution here.

Bob

> --=20
> Christoph M. Becker