[RFC][Accepted] Scalar Type Declarations V0.5

> FWIW, as someone who did play with the patch (both patches, of course), > I'm not sure why people are claiming you don't understand the RFC. Your > comments in the code are 100% accurate, which means you understood > exactly how it works.

> On 18 March 2015 at 13:12, Pavel Kouřil <pajousek@gmail.com> wrote: > > > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov <inefedor@gmail.com> > > wrote: > > > On 18 Mar 2015 15:52, "Pavel Kouřil" <pajousek@gmail.com> 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 > 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 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 > > > > >

> On 18 March 2015 at 13:12, Pavel Kouřil <pajousek@gmail.com> wrote: > > > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov <inefedor@gmail.com> > > wrote: > > > On 18 Mar 2015 15:52, "Pavel Kouřil" <pajousek@gmail.com> 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 > 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 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. > >