Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93761
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error)
MIME-Version: 1.0
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>
In-Reply-To: <BLU436-SMTP130242DCE403FFB527B7F3BE2590@phx.gbl>
Date: Sat, 04 Jun 2016 11:45:23 +0000
Message-ID: <CANUQDCgu9sgOpSsoukj_PpDk7PPV0vnMuq3wwUj-okJwZuT9Qw@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>, Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11444ba279c949053472604a
Subject: Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types
From: me@kelunik.com (Niklas Keller)

--001a11444ba279c949053472604a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bob Weinand <bobwei9@hotmail.com> schrieb am Fr., 3. Juni 2016 23:31:

>
> > Am 3.6.2016 um 18:49 schrieb Larry Garfield <larry@garfieldtech.com>:
> >
> > On 06/03/2016 10:16 AM, Jordi Boggiano wrote:
> >> On 03/06/2016 15:58, Thomas Bley wrote:
> >>> To me type declarations help to make my code easier and more
> consistent.
> >>> Having multiple scalar types for a single function parameter is
> against this goal since I need extra logic to handle this.
> >>>
> >>> e.g. function foo(string | int | bool $bar) {} makes no sense in weak
> mode since string can already handle int, bool, float, etc.
> >>>
> >>> having different behavior between
> >>> foo("42"); function foo(string $b) {echo gettype($b);} // string
> >>> and
> >>> foo("42"); function foo(string | int $b) {echo gettype($b);} // integ=
er
> >>> also makes no sense to me.
> >>>
> >>> Things like string|array are useful (e.g. str_replace) since we can
> cast the string easily to array and calling a string parameter with an
> array would give a fatal error.
> >>
> >> That is a useful case, and don't forget also return values, e.g. all
> the XX|false-kind of return types it's also nice to have.
> >>
> >> I don't think for function arguments it's massively useful and I doubt
> it'll get put everywhere, but it's nice to be able to express this when y=
ou
> have to.
> >>
> >> Cheers
> >
> > For parameters, I really don't think | is going to be the common use
> case.  (It should still be rational, but I don't expect to see it day to
> day.)  InterfaceA & InterfaceB Is the more useful use case for parameters=
.
> | is, as noted, likely more useful on returns. (even though I would
> discourage their use in most cases for reasons I won't go into here).
> >
> > --Larry Garfield
>
>
> It won=E2=80=99t and it should not be *common*. But there are legit uses =
cases:
>
>
> https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7=
768/lib/Host.php#L87
> <
> https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7=
768/lib/Host.php#L87
> >
>
> This concrete example shows that a class may implement multiple concrete
> interfaces which all get the same/similar behavior locally. [And somewher=
e
> else the code checks for each element in the array what classes it
> implements and marks them appropriately.]
> Sure, you could have ->addMiddleware($foo)->addRequest($foo) =E2=80=A6 or=
 just a
> single ->add($foo). It=E2=80=99s maybe not the most pure API, but the mos=
t
> practical one.
>
> But I agree, I myself would discourage usage of union types in most cases
> too; but there *are* legitimate cases which shall be also properly typabl=
e.
> Thus we need it.
>
> Bob


I don't see where the massively added complexity justifies the very few
edge cases. That 1% can still be checked manually.

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.

--001a11444ba279c949053472604a--