Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98177 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88315 invoked from network); 4 Feb 2017 15:15:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2017 15:15:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender) X-PHP-List-Original-Sender: php-lists@koalephant.com X-Host-Fingerprint: 206.123.115.54 mail1.25mail.st Received: from [206.123.115.54] ([206.123.115.54:55140] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/C2-38491-E10F5985 for ; Sat, 04 Feb 2017 10:15:43 -0500 Received: from [10.0.1.63] (unknown [183.89.47.214]) by mail1.25mail.st (Postfix) with ESMTPSA id 8F4266056C; Sat, 4 Feb 2017 15:15:28 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_D740B66D-7A25-4B76-9AD1-68BD42F0F923" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: <119a1b84-edff-424c-99ba-fd14cbc23ce4@Spark> Date: Sat, 4 Feb 2017 22:15:27 +0700 Cc: internals Message-ID: References: <19.45.38491.677D4985@pb1.pair.com> <611b72db-420f-4963-ab92-0ddf977a0aaa@Spark> <9AF0D2F6-D668-418C-8B96-3320D9D245ED@trowski.com> <5722B01C-A621-4C13-B34B-383B0D9753F9@koalephant.com> <22B18CB2-0383-4D4D-9B55-91A748725AC9@trowski.com> <77287A6A-C3E9-4C93-A1F2-2899DAEA8738@koalephant.com> <119a1b84-edff-424c-99ba-fd14cbc23ce4@Spark> To: Ilija Tovilo X-Mailer: Apple Mail (2.3124) Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_D740B66D-7A25-4B76-9AD1-68BD42F0F923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ilija > On 4 Feb 2017, at 17:09, ilija.tovilo@me.com wrote: >=20 > Hi Stephen >=20 >> Using type hints is a part of the language. It even has benefits that = I can absolutely see being used here: >>=20 >> array_map(function(Foo $x) =3D> $x->bar()); >>=20 >> If Foo is a class/interface with a method of bar, your IDE can know = that it's a valid method to call. >>=20 >> That of course is in addition to the benefit of getting useful type = errors from PHP itself. >=20 > I agree but think that this is the wrong approach. PHP is a weakly = typed language. Only if you omit type hints on your methods. > Doesn=E2=80=99t it seem wrong that you have to specify types in more = places than in many modern strongly typed languages? You don't *have to* specify types at all. If you want to use PHP without = verifying/requiring types, thats your prerogative, but given the recent = improvements to allow scalar type hinting, I think it=E2=80=99s a = mistake to say that *any* use of type hints is =E2=80=9Cnot = recommended". > Look at Swift for example. IMHO, the right approach would be to = implement proper closure type hints. This has the benefit of letting the = callee specify what kind of closure is expected (who knows that much = better than the caller anyway) while allowing for IDE autocompletion. I'm not sure if you've mixed up your terms of if I'm too tired but I = don't understand what you mean here. The short arrow function *is* the = callee, and that=E2=80=99s where you=E2=80=99re suggesting we = shouldn=E2=80=99t use type hints. Are you actually referring to something like = https://wiki.php.net/rfc/callable-types = or = https://wiki.php.net/rfc/typesafe-callable = where a callable type hint = can define the signature the callable should match? > Nonetheless, specifying type hints on the closures is what we do right = now. The approach Levi suggested works well with that. The whole issue with that is that using a pipe character could make = things much less clear/readable if the already established use of pipe = for =E2=80=9Ctype unions=E2=80=9D (currently used in multi-catch) were = to be implemented for general type hint usage. Note: I=E2=80=99m not saying it=E2=80=99s not possible, but it=E2=80=99s = *much* less readable, and any =E2=80=9Csolution=E2=80=9D just adds more = characters, which is apparently the only reason to not use = function($foo) =3D> $foo in the first place. >=20 >> So we should instead use syntax already used for bit wise OR, and = further confuse the situation when the function has no parameters and = reusing the logical OR operator. Brilliant. >>=20 >> This is still a function, it has slightly different semantics, just = like how a regular function, a class instance method and a static class = method have slightly different semantics: we still use the function = keyword for all of those. >>=20 >> The static keyword is used for functions, class static properties, = static variables and even static closures: it's semantics are slightly = different for each case but we reuse the same keyword. >=20 > As Levi already mentioned, this argument is similar to claiming = reusing the `function` keyword could be confusing. That was my point. There's no 'confusion' reason to not use function. = The *only* reason is to make it less characters, which several people = have noted doesn't automatically make it more readable.=20 > Both should be perfectly clear to anyone who is serious about = programming. I think we can expect for programmers to get informed about = new features before using them. This seems to work for any other = language. Also, it=E2=80=99s not like the suggested syntax is something = we=E2=80=99ve never seen before. Ruby has it, Rust has it (or something = similar at least). The rest personal preference I suppose. >=20 As has been mentioned, the rust syntax can get very hard to read very = quickly. > I can see how people like `function` more because of consistency. I = like `|| =3D> expr` more because of readability (for me, the less = reading the better :P). For most people readability isn't just about the number of characters. Cheers Stephen --Apple-Mail=_D740B66D-7A25-4B76-9AD1-68BD42F0F923--