Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85201 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68843 invoked from network); 18 Mar 2015 19:43:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2015 19:43:21 -0000 Authentication-Results: pb1.pair.com header.from=linepogl@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=linepogl@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: linepogl@gmail.com X-Host-Fingerprint: 209.85.212.169 mail-wi0-f169.google.com Received: from [209.85.212.169] ([209.85.212.169:35759] helo=mail-wi0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DF/F1-53852-755D9055 for ; Wed, 18 Mar 2015 14:43:20 -0500 Received: by wibdy8 with SMTP id dy8so99223589wib.0 for ; Wed, 18 Mar 2015 12:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0LDBjC4gJVVOzNu15XfJUVgqOoZkWY42Vl+BdbMvdRU=; b=qrSM6Cnrow6wylPL0zAB92O7W6vEa4vPN3SSULMOFCUFin57PcnD4S8vW+RFR7oaHi I/wtlZYiliqEse5rwOQwCdUA9F4FKwLBoFvvXxZtxvEXbkSt5TtakLOvllLc/xtLio9W j2BCyzgXVtYGKkkR66R7QPsLxlGOPoKgfJdtduS5nxr1BDZsIzsfm3KojA2R8DIOA+1N w0fpewOFT01XsTXdW6yRtvRLrFWPdDTiAqnO3Te7t7njqc2low45RIdQthlRQXFK8wI0 LqfTS61VjzZW3iH7YhLMifR3JhqBDUDHW5FFU60kqrMYMhkXGPI8/t03zS2yc59jTSEO MrUw== X-Received: by 10.195.11.73 with SMTP id eg9mr142414819wjd.62.1426707796641; Wed, 18 Mar 2015 12:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.99.212 with HTTP; Wed, 18 Mar 2015 12:42:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 20:42:55 +0100 Message-ID: To: Chris Wright Cc: =?UTF-8?Q?Pavel_Kou=C5=99il?= , Nikita Nefedov , PHP internals Content-Type: multipart/alternative; boundary=047d7bb709106acf680511954be2 Subject: Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5 From: linepogl@gmail.com (Lazare Inepologlou) --047d7bb709106acf680511954be2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-03-18 18:30 GMT+01:00 Chris Wright : > On 18 March 2015 at 17:07, Lazare Inepologlou wrote: > >> >> 2015-03-18 16:28 GMT+01:00 Chris Wright : >> >>> 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" wrot= e: >>> > >> >>> > >> 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 an= d >>> that >>> > > 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 sens= e >>> > 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 doc= s >>> 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 a= s >>> an >>> integer for the computation, then your code should be written to descri= be >>> 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 forc= e >>> a >>> cast hides both of these - a reader would assume the callback is always >>> called with an integer. >>> >>> >> Yet, this code has a major flaw: the type of $b cannot be statically >> inferred. >> >> No matter how "strict" the new mode is, it can only catch errors at >> runtime. This is usually too late. Having the ability to find error at >> design time is priceless. For me, this is the primary reason I am using >> type hints. >> >> > In the case where the caller may or may not be passing an int (i.e. the > case where the original example would error because of strict mode in the > lib), the type cannot be inferred through static analysis no matter what > you do, at least not correctly, because it has no definite type. Since > there is currently no "number" union type it is "mixed", which is the > default "type" for any variable. > > Let me be more clear. The type of $b cannot be statically inferred here: a(function($b) {return ((int)$b) * 2; }) But it can be inferred here: a(function(int $b) {return $b * 2; }) So I would always prefer to use the second form, especially if the closure was more complex. However, it seems that the second form is possible to fail, and that depends on the mode (strict or not) of the library that contains the function a. It does not depend on the mode that I have chosen to work with. The two closures will not work in the same way and that's a kind of a WTF moment. Lazare INEPOLOGLOU Ing=C3=A9nieur Logiciel > >> >> Lazare INEPOLOGLOU >> Ing=C3=A9nieur Logiciel >> >> >> >> >>> >>> > >>> > >> 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 whe= re >>> > >> 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 i= t >>> > the other way around. >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> > >>> >> >> > --047d7bb709106acf680511954be2--