Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85196 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44683 invoked from network); 18 Mar 2015 15:28:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2015 15:28:39 -0000 Authentication-Results: pb1.pair.com header.from=are.you.winning@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=are.you.winning@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender) X-PHP-List-Original-Sender: are.you.winning@gmail.com X-Host-Fingerprint: 209.85.212.169 mail-wi0-f169.google.com Received: from [209.85.212.169] ([209.85.212.169:38310] helo=mail-wi0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C1/D1-32095-5A999055 for ; Wed, 18 Mar 2015 10:28:38 -0500 Received: by wifj2 with SMTP id j2so42982643wif.1 for ; Wed, 18 Mar 2015 08:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=urhccSi0h+TdWsHFCO9TbYu9Dd5iI2wurmGROdQqWZ8=; b=jybRN6llMixgD0G3RZ1xTmCyS+IGbeCGx4Uu1B3fYbxr4EoWKYzQkDQwnET2C4YpR5 VsbU3HvsI4E3QMqnWAwqcqvfjQ3y81C50nv9l3T4VqB5S4kAxGwDSgV81w7qOt/R4mSl tT3vLEtVYMdFZjna9Mrg99bEA2OTZFfNIp+E79EGXq9KfGJPQcKhVOlvDR4yL8NgSqSG AJhrfmpoT5AaFbNGw9BV8hXojpPPge7VX5JcH+RWWpp6RaGv5zbrRy1BPCkZ1hLJaZWL wrzY6OYUTnyvFfpLnMG8Q6+QPQFA81Nxlg2tkdjwyHykw6Gz50czzGCNyykaU9NQlcog ApUg== MIME-Version: 1.0 X-Received: by 10.194.177.132 with SMTP id cq4mr137352332wjc.99.1426692514853; Wed, 18 Mar 2015 08:28:34 -0700 (PDT) Sender: are.you.winning@gmail.com Received: by 10.180.109.233 with HTTP; Wed, 18 Mar 2015 08:28:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 15:28:34 +0000 X-Google-Sender-Auth: a5A4-GtSELqDcs6o5jJqNUorjLw Message-ID: To: =?UTF-8?Q?Pavel_Kou=C5=99il?= Cc: Nikita Nefedov , PHP internals Content-Type: multipart/alternative; boundary=089e014942e68d3a03051191bc56 Subject: Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5 From: cw@daverandom.com (Chris Wright) --089e014942e68d3a03051191bc56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 March 2015 at 13:12, Pavel Kou=C5=99il wrote: > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov > wrote: > > On 18 Mar 2015 15:52, "Pavel Kou=C5=99il" wrote: > >> > >> Hello, > >> > >> I made that conclusion because in the first example, the library kinda > >> forces strict mode rules on the caller, even if he doesn't want to use > >> strict mode - this makes the interoperability of the two modes > >> problematic. > > > > This is incorrect, library force itself to use right types, not you. I > don't > > see any problems here. The only thing that for sure lacks in PHP and th= at > > would make STH better is callable signature types. > > > > Well, it forces you to do that, basically. And also forces you to > "care" about the mode of library, adding mental overhead. Look more > closesly at the first example - does the error in that case make sense > to you (from purely user's point of view)? When you call > a(function(int $b) {return $b * 2; }) - should you really be required > to check the context within the a() is declared? > You don't need to check the declaration context of a(). Either the library is definitely passing an integer and your code will work, or it isn't definitely passing an integer, maybe it's a float, so you shouldn't declare the parameter type at all - it isn't a typed parameter. This is simply a matter of RTFM in the library docs (and if there are no docs or the docs are wrong then you have to go read the library code anyway just as you would today, so you haven't lost anything). Type declarations are a way to more completely describe the interface contract, they are *not* a replacement/shorthand for casts. If the desired behaviour for your callback should be to accept anything and treat it as an integer for the computation, then your code should be written to describe that intent, i.e: a(function($b) {return ((int)$b) * 2; }) This code both describes the behaviour of a() and the programmer's intended behaviour for the callback. Using a type declaration as a means to force a cast hides both of these - a reader would assume the callback is always called with an integer. > > >> Also, the other possible outcome of the scenario (respecting the mode > >> of the place where the callback is declared), is IMHO problematic as > >> well, because it does not respect the strict mode of the place where > >> it is called, making it inconsistent with how the dual mode RFC works > >> in general. > > > > It doesn't matter where the callback or function was declared, it only > > matters where it was called. It pretty much is consistent. > > This was just a comment about how it would be (also) wrong to solve it > the other way around. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --089e014942e68d3a03051191bc56--