Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92863
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4Nozvf=9yEbaBpe6Zjd1pidnOAH=FjVNNLVzoB6gTz-POg@mail.gmail.com>
References: <CAFMT4Nozvf=9yEbaBpe6Zjd1pidnOAH=FjVNNLVzoB6gTz-POg@mail.gmail.com>
Date: Thu, 28 Apr 2016 10:00:01 +0100
Message-ID: <CAKiSzdC3JmevOGfTYBcRgMbsCrMEB7POU8WrkBRNM1Nhq8-TDw@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Intersection Types
From: joshdifabio@gmail.com (Josh Di Fabio)

On Thu, Apr 28, 2016 at 4:54 AM, Levi Morrison <levim@php.net> wrote:
> Internals,
>
> As alluded to last week I have another RFC for improving the type
> system: [intersection types][1].
>
> It allows parameters to define multiple type constraints that must be
> satisfied. Common combinations of our built-in types include
> `ArrayAccess & Traversable & Countable` and `Countable & Iterator`.
>
> Some people have suggest I merge this and union types into one RFC.
> For now I'll just proceed with them separately to gain feedback.
>
>   [1]: http://wiki.php.net/rfc/intersection_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

To me, it seems that intersection types are more useful than union
types (other than the obvious null|Foo and array|Traversable cases) as
they'd allow us to write smaller interfaces and better follow ISP in
userland, with interfaces becoming much more convenient for
documenting the requirements of a parameter.

At present we tend to have incomplete implementations of interfaces
(e.g. throw OperationNotSupportedException). Union types would allow
us to create more, smaller interfaces and avoid situations where the
type of a parameter doesn't accurately reflect the method's true
requirements, or where concretions are incomplete implementations of
an interface.

Thanks for your efforts, Levi, I'm excited about this one!