Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93980
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.82 as permitted sender)
Message-ID: <BLU436-SMTP229A6659FF8E068F2E78C2E2540@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_04F9AECC-8FB5-46EA-BBE4-8821A7A0065E"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAFMT4Nor07B1tSv3hTa2HazCCrcLC8RCY3T5Vn7vPfu420_jFA@mail.gmail.com>
Date: Tue, 14 Jun 2016 22:43:31 +0200
CC: Zeev Suraski <zeev@zend.com>,
 Stanislav Malyshev <smalyshev@gmail.com>,
 PHP internals <internals@lists.php.net>,
 Derick Rethans <derick@php.net>
References: <BLU436-SMTP259DA83A3D76B48FDB9F28AE2540@phx.gbl> <alpine.DEB.2.20.1606141621580.4314@whisky.home.derickrethans.nl> <a4c32728-2ce6-dc6a-70cb-2c0241f31f91@fleshgrinder.com> <BLU437-SMTP5110966FC3D3866E4A3E05E2540@phx.gbl> <8d26c709-2083-40ac-3bb5-cddc0ecef4bd@gmail.com> <6B3C4F2A-22D6-4004-9F14-5E43EA8AD52A@zend.com> <CAFMT4Nor07B1tSv3hTa2HazCCrcLC8RCY3T5Vn7vPfu420_jFA@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Union types
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_04F9AECC-8FB5-46EA-BBE4-8821A7A0065E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"


> Am 14.6.2016 um 21:53 schrieb Levi Morrison <levim@php.net>:
>=20
>> I'm personally against Union types because it makes no sense for =
classes
>=20
> I've been over this before but I'll repeat it here for completeness:
> this is not true. Unions provide a way to discriminate between
> potential sets of types. Even among classes there is power in unions.
> Consider the idea of encoding a Something or Nothing with methods such
> as `map`, `flatmap`, `filter`, etc.
>=20
> A Something will return a Something for map, and a Nothing will return
> a Nothing. By using inheritance there are two problems:
>=20
>  1. We can create additional subclasses that do not obey the
> semantics of the type. Imagine how frustrating a stack that does not
> behave like a stack would be; same principle here.
>  2. We don't have covariant return types so we cannot express that
> Nothing::map will return Nothing and Something::map will return
> Something.
>=20
> Using two final classes for Something and Nothing and then doing a
> union on them has neither of these downsides. Even if we add return
> type covariance we cannot solve problem 1.
>=20
> Given that there are numerous other uses with built-in types such as
> Array | Traversable (iterable), int | string (array key), int | float
> (numeric) and so forth it does not make sense to me to special case
> these things. Generality is better for language features than special
> casing.

What Levi tries to explain: unions are like a temporary virtual =
super-interface to any accepted class without actually being implemented =
by them.

Typically you are writing adapters for these things, but an adapter is =
not always the solution (i.e. in cases where a part of the handling is =
identical, but depending on the actual class (instanceof) they =
ultimately get dispatched to somewhere else).
For exactly these cases (which, I admit, aren=E2=80=99t numerous [The =
cases where it=E2=80=99s legitimate and there is no other superior =
solution]) union classes are helpful.

Bob





--Apple-Mail=_04F9AECC-8FB5-46EA-BBE4-8821A7A0065E--