Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93974
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.44 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <6B3C4F2A-22D6-4004-9F14-5E43EA8AD52A@zend.com>
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>
Date: Tue, 14 Jun 2016 13:53:10 -0600
Message-ID: <CAFMT4Nor07B1tSv3hTa2HazCCrcLC8RCY3T5Vn7vPfu420_jFA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Bob Weinand <bobwei9@hotmail.com>, 
	PHP internals <internals@lists.php.net>, Derick Rethans <derick@php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [VOTE] Union types
From: levim@php.net (Levi Morrison)

> I'm personally against Union types because it makes no sense for classes

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.

A Something will return a Something for map, and a Nothing will return
a Nothing. By using inheritance there are two problems:

  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.

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.

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.