Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93763 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61473 invoked from network); 4 Jun 2016 12:15:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jun 2016 12:15:08 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.77 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.77 blu004-omc2s2.hotmail.com Received: from [65.55.111.77] ([65.55.111.77:53558] helo=BLU004-OMC2S2.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/C3-25194-B46C2575 for ; Sat, 04 Jun 2016 08:15:08 -0400 Received: from BLU436-SMTP86 ([65.55.111.72]) by BLU004-OMC2S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 4 Jun 2016 05:15:05 -0700 X-TMN: [gb1jYG/RqvOk7gL8An1+gym4YUVfvYP5] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_3AC3A4BF-37C7-4869-BE0F-60BA015D78EA" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) In-Reply-To: Date: Sat, 4 Jun 2016 14:15:00 +0200 CC: Larry Garfield , internals@lists.php.net References: <0A.C5.62101.1C860575@pb1.pair.com> <68b821ac-d71f-4be5-8dca-ae94db332630@gmail.com> <20160603101659.D466A1A81FC5@dd1730.kasserver.com> <6d448fd8-8fda-d795-accb-6b96cd128ccd@gmail.com> <652fdc5a-a164-2054-ed61-305a2b72330a@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> To: Niklas Keller X-Mailer: Apple Mail (2.3112) X-OriginalArrivalTime: 04 Jun 2016 12:15:03.0290 (UTC) FILETIME=[B9237DA0:01D1BE5A] Subject: Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_3AC3A4BF-37C7-4869-BE0F-60BA015D78EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > Am 04.06.2016 um 13:45 schrieb Niklas Keller : >=20 > Bob Weinand > schrieb = am Fr., 3. Juni 2016 23:31: >=20 > > Am 3.6.2016 um 18:49 schrieb Larry Garfield >: > > > > 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);} // = integer > >>> 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 you 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 >=20 >=20 > It won=E2=80=99t and it should not be *common*. But there are legit = uses cases: >=20 > = https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec77= 68/lib/Host.php#L87 = = > >=20 > This concrete example shows that a class may implement multiple = concrete interfaces which all get the same/similar behavior locally. = [And somewhere 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 most practical one. >=20 > 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 = typable. Thus we need it. >=20 > Bob >=20 > I don't see where the massively added complexity justifies the very = few edge cases. That 1% can still be checked manually. Massive is a nice hyperbole here... Sure, you can check it manually=E2=80=A6 but why not just always check = it manually then? You then loose possibilities to reflect on it, have static analysis rely = on code only [currently you always have to check docblocks when it's not = declared; definitely not an option for e.g. Optimizer], and a single = signature is generally easier to parse for a human. Also, I don't believe it's the languages task to put arbitrary = limitations on this. If a library does this, that's the libraries = problem. But a language should not do that and try to support full = typing. We've decided to make PHP (opt-in) typed on function boundaries = (and eventually soon on property storage boundaries), so we should also = finish what we committed to instead of putting something half-arsed = forward. > 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. As you say, disadvantage of callable. 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. 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. Bob= --Apple-Mail=_3AC3A4BF-37C7-4869-BE0F-60BA015D78EA--