Re: [PHP-DEV] Reviving scalar type hints
On Fri, Feb 20, 2015 at 10:48 PM, Robert Stoll p...@tutteli.ch wrote: Hi Dmitry and Anthony, I was skimming through your conversation about JIT/AOT and that type hints would allow to optimise few things. I do not know if you are aware of the following but type hints can be passed by. Hence neither weak or strict type hints allow to predict the type (even if only locally): function handler($errno, $errstr, $errfile, $errline){ return true; } set_error_handler(handler); class Foo{} function foo(int $x, Foo $f){ var_dump($x, $f); $y = $x; //should be int as well, right? } foo(new Foo(), 1); Sure, this is something which is hopefully never ever done but anyway, a language needs to be able to handle all cases. right. I know this of course. and this makes type hints useless. As a side notice, if the exceptions in the engine RFC is accepted, then this would not be a problem anymore: https://wiki.php.net/rfc/engine_exceptions_for_php7 exceptions in the engine are going to fix this. Thanks. Dmitry. Personally, I would expect that the execution is stopped after the error_handler was called (after user was able to log etc.) - at least in strict mode. Cheers, Robert
Re: [PHP-DEV] Reviving scalar type hints
2015-02-21 17:26 GMT-04:00 Pavel Kouřil pajou...@gmail.com: Hello, finally got to this, after a while of thinking - the first part was answered before, so I'll get only to the str_replace now. :) Basically, each of the 8 different version based on parameters does different thing, if I'm counting it correctly. So having 8 different declarations is IMHO valid. I know it sounds a little bit weird, but if you really realize the amount of things the function is doing based on the passed parameters, why would having one declaration with multiple argument types and if statements deciding what to do based on an argument types be better than 8 different declarations, where each one does one predictable thing and can be documented separately? :) PS: I know there's something like a declined RFC for method overloading in the wiki (actually, just a 7 years old email), but if there would be someone who would be interested in having method overloading in PHP and understands PHP's internals (I don't) so he'd be able to make the implementation, I'd like to discuss this idea with him more and contribute somehow to a possible RFC. Regards Pavel Kouril I recently discovered this compact and lean implementation of PHP (ph7) which has overloading, scalar hinting and other nice features, so besides hhvm it could serve as an inspiration for those working on RFC's github.com/symisc/PH7 Would be nice to have function overloading on PHP now that theres going to be scalar type hinting (luckily at some point), its the best a proven approach to deal with different parameter types in a clean and straightforward way. Also some functionality at the PHP C level (when developing extensions) to register various overloads would be nice. When working on the wxWidgets wrapper for PHP I had to mix all function/method overloads into a single function which isn't too easy to do on an automated way (github.com/wxphp/wxphp/blob/master/src/media.cpp#L170). Also when working on an IDE like NetBeans it is a mess to supply an interface file for auto-completion with methods/functions that have different overloads. This kind of things may at first look like conflicting with original PHP goals, but they are pretty useful once you understand them.
Re: [PHP-DEV] Reviving scalar type hints
Francois, On Fri, Feb 20, 2015 at 8:14 PM, François Laupretre franc...@php.net wrote: Hi Anthony, I guess you would keep supporting __toString() ? So, you should probably consider 'string' as 'string|object'. Adding this case to 'float' meaning 'int|float' and 'callable' resolving to 'string|array|object', are you sure it's worth the pain implementing and supporting a dual-mode mechanism, compared to the ruleset I am intending to propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rules ? No. The rules are quite clearly explained in the RFC. The only thing that can resolve a string hint is a string. __toString is a form of cast, and hence disallowed in strict mode (because 1: it's not explicit, 2: it loses significant information). Callable is an existing rule, which is not subject to the strict discussion. Actually, using such ruleset, I guess you could infer less, but the difference wouldn't be so important. Only 3 conversions still use value, from which one can be made type-dependent-only if requested during discussion (float to int proposed as lossless-only). Every type except int, float, and string are also proposed as 100% strict. None of the conversions use value. Int, Float, String and Bool all behave precisely about type. No runtime value information is used (only runtime type info). Please read the proposal and see what it says. Don't judge it by what you assume, but by what it says. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Zeev, Anthony, Following Adam's analysis of the timeline, taking the more 'strict' (no pun intended!) interpretation of the timeline RFC, we still have until tomorrow to start the discussion and still target it for 7.0, no? Given the importance of this topic, I'd go for the more lax interpretation that allows for votes to begin by March 15, giving us all a bit more time to discuss. I don't think any of us, on any camp, wants to wait for 2016 for this. Thoughts? I'm fine with that. My interpretation was that the feature freeze would happen on March 15 (that afterwards no new RFCs would be accepted). I made the decision to target 7.next/8 based on the assumption that the competing RFC would not be able to fairly target 7.0. If you are saying that's not the issue, then I'll happily re-target this RFC for 7.0 again. I just didn't want to be seen as (or actually do) pushing based on a timing advantage that your proposal couldn't possibly meet. So if you're fine with it (which it seems you are), I'll re-target the RFC now. Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Saturday, February 21, 2015 5:23 PM To: Zeev Suraski Cc: Larry Garfield; internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints I'm fine with that. My interpretation was that the feature freeze would happen on March 15 (that afterwards no new RFCs would be accepted). I made the decision to target 7.next/8 based on the assumption that the competing RFC would not be able to fairly target 7.0. If you are saying that's not the issue, then I'll happily re-target this RFC for 7.0 again. I just didn't want to be seen as (or actually do) pushing based on a timing advantage that your proposal couldn't possibly meet. So if you're fine with it (which it seems you are), I'll re-target the RFC now. I am fine with it, as long as we all agree for the lax interpretation of the March 15 deadline (vote must start by then). Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Saturday, February 21, 2015 1:36 AM To: Larry Garfield Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints Larry, On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com wrote: On 02/20/2015 06:28 PM, Anthony Ferrara wrote: Considering I'm not targetting 7 (I've updated the RFC to hint this), we can choose what to do later depending on the exceptions result (whether to bypass execution in strict mode only, or for all calls). Thanks for the insight Anthony That makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. Timing just won't work while being fair with alternative proposals. I've said since I re-opened the proposal that I'm comfortable with it not targeting 7.0... Unless we're willing to push feature freeze by 2-3 weeks for it, it just doesn't make sense to target 7 with people working on an alternate proposal (since by definition they couldn't target 7). Anthony, Following Adam's analysis of the timeline, taking the more 'strict' (no pun intended!) interpretation of the timeline RFC, we still have until tomorrow to start the discussion and still target it for 7.0, no? Given the importance of this topic, I'd go for the more lax interpretation that allows for votes to begin by March 15, giving us all a bit more time to discuss. I don't think any of us, on any camp, wants to wait for 2016 for this. Thoughts? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Francois, Adding this case to 'float' meaning 'int|float' and 'callable' resolving to 'string|array|object', are you sure it's worth the pain implementing and supporting a dual-mode mechanism, compared to the ruleset I am intending to propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rules ? I've taken a look at that proposal, and here are my comments: 1. This RFC only talks about ZPP. I assume you're also talking about exposing the same ruleset to userland? 2. You're talking about making passing `1` to a bool parameter disallowed by default. Meaning that a **LOT** of code will break automatically when upgrading to 7. Because internal function's error behavior will change. This **will** likely create a python 2/3 situation here. You're making a MASSIVE bc break here. If you were just talking about user-land types, that would be one thing. But since you're explicitly talking about ZPP, this is a bad thing. 3. It still doesn't solve the problems the strict type proponents are looking to have solved (namely that the type is what's checked, not the value). The is_numeric_string cleanup is definitely a step in the right direction (and I think should be implemented anyway), but it still doesn't solve the problem. Overall, this proposal feels like a compromise in a bad way. It makes existing code error (bc break), doesn't give the weak proponents what they want and doesn't give the strict proponents what they want either. Just because it's the middle ground doesn't make it a good thing. Please consider these issues seriously prior to making the proposal official. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Anthony Ferrara [mailto:ircmax...@gmail.com] Callable is an existing rule, which is not subject to the strict discussion. I was talking of __invoke() and closures, wich extend callable from 'string|array' to 'string|array|object'. But, I agree, it just extends the rule. None of the conversions use value. Int, Float, String and Bool all behave precisely about type. No runtime value information is used (only runtime type info). I was talking of errors being raised depending on value (non-numeric string and others). And I was talking about the ZPP proposal I wrote, not yours. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote: De : Pavel Kouril [mailto:pajou...@gmail.com] Hello, I know this is probably a pretty unpopular opinion in PHP (based on the replies I got in the other thread), but different values for parameters should be IMHO solved by method overloading and such. The question is not that it's unpopular, it's that 1. It requires strict types, and 2. If we want to solve this by polymorphism, we must also support polymorphism on functions. Now, tell me how you would solve the tan(int|float) case with polymorphism ? One 'tan' function for int, one for float ? str_replace(string|array, string|array, string|array, int ) is also a nice case to study if you can't sleep... Sorry but polymorphism on scalar types is possible with strict types only, which is out of scope for the next RFC. François Hello, finally got to this, after a while of thinking - the first part was answered before, so I'll get only to the str_replace now. :) Basically, each of the 8 different version based on parameters does different thing, if I'm counting it correctly. So having 8 different declarations is IMHO valid. I know it sounds a little bit weird, but if you really realize the amount of things the function is doing based on the passed parameters, why would having one declaration with multiple argument types and if statements deciding what to do based on an argument types be better than 8 different declarations, where each one does one predictable thing and can be documented separately? :) PS: I know there's something like a declined RFC for method overloading in the wiki (actually, just a 7 years old email), but if there would be someone who would be interested in having method overloading in PHP and understands PHP's internals (I don't) so he'd be able to make the implementation, I'd like to discuss this idea with him more and contribute somehow to a possible RFC. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Anthony Ferrara [mailto:ircmax...@gmail.com] I've taken a look at that proposal, and here are my comments: Thanks 1. This RFC only talks about ZPP. I assume you're also talking about exposing the same ruleset to userland? Right. This is a sub-RFC of STH main. As it is stated in introduction, STH is based on ZPP and follows its ruleset. 2. You're talking about making passing `1` to a bool parameter disallowed by default. Meaning that a **LOT** of code will break automatically when upgrading to 7. Because internal function's error behavior will change. 2 days ago, we took time to discuss about this, and decided we should proceed in several steps : 1. Implement a first version of the ruleset and ask list members to pre-validate on different PHP software. Massive BC breaks would appear quickly. 2. If massive BC breaks appear, find a minimal way to fix, while keeping ruleset consistency. The only case we were hesitating about for a first test is conversion to bool. I initially proposed to keep existing rules, just extending (string - bool) to consider *every* numeric string that would give a null number should be converted to false, not just 0. Thought it was necessary because, today 0 and 0 give (int)0, but 0 is false and 0 is true. Zeev didn't like this, so consistency dictated to start with (string/float/int - bool) totally disabled, and check for massive break IRL. I didn't want to make it a voting option because I feel like you about voting options. Now, your opinion confirms that time is probably too short to organize such test before vote begins. So, I'll modify the RFC to revert back to what I explained above. If people allow, I'll try to stick to the (string - bool) minor modification I wanted to propose, but that's detail. If you were just talking about user-land types, that would be one thing. But since you're explicitly talking about ZPP, this is a bad thing. As previously said , I won't propose userland-only rules, except probably 'resource' to accept IS_RESOURCE and IS_OBJECT, but that's different story. 3. It still doesn't solve the problems the strict type proponents are looking to have solved (namely that the type is what's checked, not the value). The is_numeric_string cleanup is definitely a step in the right direction (and I think should be implemented anyway), but it still doesn't solve the problem. We all agree here. Cannot use type-only if 31 accepted as 31. I could just limit value to be used in as few cases as possible, but it is not a complete no-go in my opinion as it just forces a tool to consider 'int' as a potential union of IS_STRING|IS_LONG|IS_FLOAT, instead of IS_INT. As any tool analyzing PHP code will have to support some unions like this, it will cause some cases to be undetected but it does not kill the concept of static analysis for PHP. There are also lots of ways to restrict possible zval types by analyzing the code. Remember arguments are systematically converted to known zval types on function entry, this helps a lot. I won't go further because you're an expert on the subject and I'm not. Overall, this proposal feels like a compromise in a bad way. It makes existing code error (bc break), doesn't give the weak proponents what they want Examples of not solving weak proponent needs (except conversion to bool which will be reverted) ? and doesn't give the strict proponents what they want either. Just because it's the middle ground doesn't make it a good thing. Not perfect, yes, but I still favor the approach, compared to the assertion that 1 proposal + 1 proposal takes the best of both. Please consider these issues seriously prior to making the proposal official. We are talking draft. Not sure yet it goes official one day. Thanks François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
hi Dmitry, On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. I think we can agree on that, and we did as far as I can tell :) However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. Let put things correctly please: In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote: hi Dmitry, On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. What is significant? Miracle ability of static analyzes for AOT? I think we can agree on that, and we did as far as I can tell :) I didn't agree with you. Probably, I told that performance impact of run-time switch of type hinting semantic is slightly negative and it would be great to fix it if possible. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. Let put things correctly please: In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. I didn't hear any arguments for strict typing except for program verification and static analyzes, may be I missed. Please, tell me few use cases, may be it'll change my mind :) Thanks. Dmitry. Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] Reviving scalar type hints
Dmitry On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote: hi Dmitry, On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. What is significant? Miracle ability of static analyzes for AOT? Please, can we discuss something without snark? And can we get past AOT? It's distracting. I only mentioned it here because I was specifically asked about it. It's not in my RFC. So please, let's get past it. I think we can agree on that, and we did as far as I can tell :) I didn't agree with you. Probably, I told that performance impact of run-time switch of type hinting semantic is slightly negative and it would be great to fix it if possible. Everyone is saying this shouldn't be voted on based on performance. You, me, Pierre, everyone. Additionally, the negative impact could be solved by introducing a new opcode for scalar checks, pushing any performance difference to compile time. But I'd like to see some measurments of the performance difference prior to going down that road. In short, the negative performance difference is either going to be negligible (won't appear on a benchmark) or can more than likely be made negligible without a terrible amount of work. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. Let put things correctly please: In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. I didn't hear any arguments for strict typing except for program verification and static analyzes, may be I missed. Please, tell me few use cases, may be it'll change my mind :) verification and static analysis aren't enough? Seriously, equating static analysis to a few unit tests is either un-unnecessarily hyperbolic or a complete misconsurance of the point. Unit tests at best tell you that the code behaves as the tests say. Those tests can be bogus, but the tests still pass. Static analysis on the other hand can tell you if the code is semantically correct or not (whether or not errors can/will be thrown). The type system provides a lower bound on correctness. The unit tests at best establish an upper bound.
Re: [PHP-DEV] Reviving scalar type hints
On 02/20/2015 06:28 PM, Anthony Ferrara wrote: Considering I'm not targetting 7 (I've updated the RFC to hint this), we can choose what to do later depending on the exceptions result (whether to bypass execution in strict mode only, or for all calls). Thanks for the insight Anthony That makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Larry, On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com wrote: On 02/20/2015 06:28 PM, Anthony Ferrara wrote: Considering I'm not targetting 7 (I've updated the RFC to hint this), we can choose what to do later depending on the exceptions result (whether to bypass execution in strict mode only, or for all calls). Thanks for the insight Anthony That makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. Timing just won't work while being fair with alternative proposals. I've said since I re-opened the proposal that I'm comfortable with it not targeting 7.0... Unless we're willing to push feature freeze by 2-3 weeks for it, it just doesn't make sense to target 7 with people working on an alternate proposal (since by definition they couldn't target 7). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Robert, On Fri, Feb 20, 2015 at 2:48 PM, Robert Stoll p...@tutteli.ch wrote: Hi Dmitry and Anthony, I was skimming through your conversation about JIT/AOT and that type hints would allow to optimise few things. I do not know if you are aware of the following but type hints can be passed by. Hence neither weak or strict type hints allow to predict the type (even if only locally): function handler($errno, $errstr, $errfile, $errline){ return true; } set_error_handler(handler); class Foo{} function foo(int $x, Foo $f){ var_dump($x, $f); $y = $x; //should be int as well, right? } foo(new Foo(), 1); Sure, this is something which is hopefully never ever done but anyway, a language needs to be able to handle all cases. As a side notice, if the exceptions in the engine RFC is accepted, then this would not be a problem anymore: https://wiki.php.net/rfc/engine_exceptions_for_php7 Personally, I would expect that the execution is stopped after the error_handler was called (after user was able to log etc.) - at least in strict mode. That's a very good point. Ideally exceptions will help there as it will simplify things significantly. But even without them, it should be possible to bypass execution. Considering I'm not targetting 7 (I've updated the RFC to hint this), we can choose what to do later depending on the exceptions result (whether to bypass execution in strict mode only, or for all calls). Thanks for the insight Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Fri, Feb 20, 2015 at 3:36 PM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com wrote: On 02/20/2015 06:28 PM, Anthony Ferrara wrote: Considering I'm not targetting 7 (I've updated the RFC to hint this), we can choose what to do later depending on the exceptions result (whether to bypass execution in strict mode only, or for all calls). Thanks for the insight Anthony That makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. Timing just won't work while being fair with alternative proposals. I do not think it is unfair to push it now. In contrary. I've said since I re-opened the proposal that I'm comfortable with it not targeting 7.0... Unless we're willing to push feature freeze by 2-3 weeks for it, it just doesn't make sense to target 7 with people working on an alternate proposal (since by definition they couldn't target 7). I do think we should. We are exactly at the point I was afraid to reach with the unrealistic planning for 7. Engine is somehow stable from an API changes point of view, so other can start to work on a couple of key features. But it is too late. Let face it, some features (like your RFC) will never make it post 7.0. We have to be realistic about how things work now. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Hi Anthony, I guess you would keep supporting __toString() ? So, you should probably consider 'string' as 'string|object'. Adding this case to 'float' meaning 'int|float' and 'callable' resolving to 'string|array|object', are you sure it's worth the pain implementing and supporting a dual-mode mechanism, compared to the ruleset I am intending to propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rules ? Actually, using such ruleset, I guess you could infer less, but the difference wouldn't be so important. Only 3 conversions still use value, from which one can be made type-dependent-only if requested during discussion (float to int proposed as lossless-only). Every type except int, float, and string are also proposed as 100% strict. I'm not sure we can go much further with a single-mode approach, but I'll appreciate your opinion. Of course, anyone else is welcome too. Regards François -Message d'origine- De : Anthony Ferrara [mailto:ircmax...@gmail.com] Envoyé : vendredi 20 février 2015 02:58 À : Larry Garfield Cc : internals@lists.php.net Objet : Re: [PHP-DEV] Reviving scalar type hints Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. So that means one less branch (no guard) per argument per function call. In addition, native calls can be used in a lot of cases, which means the compiled code doesn't even need to know about a zval (significant memory and access reduction). This has potential to be significant. Not to mention the other optimizations that are possible. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote: verification and static analysis aren't enough? Anthony, While IMHO they're not enough to warrant substantial deviation from PHP's behavior, this is a subjective question that others might answer differently. But there's also an objective issue. There's a serious question mark whether the type of hint - strict, coercive of otherwise can have any sort of implications on one's ability to conduct static analysis, JIT or AOT (I'm bringing those up again since they're closely related in terms of what you can or cannot infer). Now, I'll contend that even though I don't think we are, perhaps we're missing something. But at the very least it should be clear to the list there's serious doubt on whether there's any extra value there even if they do seem static analysis critical. If there is, it's likely to be very, very limited in scope. That's not saying you should want to use statically typed for everything. And nor would I support PHP moving to pure statically typed (which is why the proposal I'm backing doesn't). We're on the same page here. But the kinds of static analysis benefits you seem to believe we can get from strict type hints would require that - strong typing, variable declarations, perhaps changes to casting rules - not just around that narrow interface between callers and callees. Thankfully that's not on the table. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Zeev, On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote: On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote: verification and static analysis aren't enough? Anthony, While IMHO they're not enough to warrant substantial deviation from PHP's behavior, this is a subjective question that others might answer differently. But there's also an objective issue. There's a serious question mark whether the type of hint - strict, coercive of otherwise can have any sort of implications on one's ability to conduct static analysis, JIT or AOT (I'm bringing those up again since they're closely related in terms of what you can or cannot infer). Now, I'll contend that even though I don't think we are, perhaps we're missing something. But at the very least it should be clear to the list there's serious doubt on whether there's any extra value there even if they do seem static analysis critical. If there is, it's likely to be very, very limited in scope. Let's simply agree to disagree here :-) That's not saying you should want to use statically typed for everything. And nor would I support PHP moving to pure statically typed (which is why the proposal I'm backing doesn't). We're on the same page here. But the kinds of static analysis benefits you seem to believe we can get from strict type hints would require that - strong typing, variable declarations, perhaps changes to casting rules - not just around that narrow interface between callers and callees. Thankfully that's not on the table. That's also not necessary in most cases. You can infer a lot about the types of variables just having arguments declared. In most cases, you can infer enough for static analysis to work. In the cases you can't, that's actually a valid result of the analysis because you may have undefined behavior. Example: function foo(string $a): int { return $a + 1; } You can't infer the type of $a+1 because the conversion of $a-numeric that happens is unstable from a type perspective. But PHP's type changes are predictable enough where the majority of sane cases are predictable. Both Swift and Go behave like this. Where you only *need* explicit declarations on the arguments, the rest can be inferred. And where it can't infer, it raises a type error. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Feb 20, 2015 11:08 AM, Anthony Ferrara ircmax...@gmail.com wrote: Zeev, On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote: On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote: verification and static analysis aren't enough? Anthony, While IMHO they're not enough to warrant substantial deviation from PHP's behavior, this is a subjective question that others might answer differently. But there's also an objective issue. There's a serious question mark whether the type of hint - strict, coercive of otherwise can have any sort of implications on one's ability to conduct static analysis, JIT or AOT (I'm bringing those up again since they're closely related in terms of what you can or cannot infer). Now, I'll contend that even though I don't think we are, perhaps we're missing something. But at the very least it should be clear to the list there's serious doubt on whether there's any extra value there even if they do seem static analysis critical. If there is, it's likely to be very, very limited in scope. Let's simply agree to disagree here :-) That's not saying you should want to use statically typed for everything. And nor would I support PHP moving to pure statically typed (which is why the proposal I'm backing doesn't). We're on the same page here. But the kinds of static analysis benefits you seem to believe we can get from strict type hints would require that - strong typing, variable declarations, perhaps changes to casting rules - not just around that narrow interface between callers and callees. Thankfully that's not on the table. That's also not necessary in most cases. You can infer a lot about the types of variables just having arguments declared. In most cases, you can infer enough for static analysis to work. In the cases you can't, that's actually a valid result of the analysis because you may have undefined behavior. Example: function foo(string $a): int { return $a + 1; } You can't infer the type of $a+1 because the conversion of $a-numeric that happens is unstable from a type perspective. But PHP's type changes are predictable enough where the majority of sane cases are predictable. Both Swift and Go behave like this. Where you only *need* explicit declarations on the arguments, the rest can be inferred. And where it can't infer, it raises a type error. Anthony OK, performance is out then. :-) Anthony, please explain this to me next: Assume for a moment that: - we tighten up the default passing rules, such that 32 passed to an int works but 32 footsteps errors (which I thing most are on board with doing) - we include a strict types mode as proposed, including the logical type widening cases - Zend Engine gets whatever static analysis tools you feel are appropriate. In what circumstances would I as a Drupal core developer (a few hundred thousand lines of code, need high degree of correctness, 2500 developers), contrib developer (a few thousand lines of code, medium correctness guarantee, 3 developers), or a client consultant (a few hundred lines of custom one-off code, 1 developer) want to enable strict mode? Using strict typing would out more work on me. How much varies with the part of the application. (Closer to IO, more work.) Having it in the language means I will run into it sometime, even if not in code I originate. If potential performance is not a factor, then what is my carrot? What day to day benefit would I get from doing so other than pedantry?[1] You can infer things doesn't make it clear what the day to day impact is for me. Concrete examples, please. If it would only matter to the Facebook's of the world, well, they've got HACK already. How would this practically help Drupal, Symfony, Zend Framework, OwnCloud, Doctrine, phpMyAdmin, etc? [1] I'm hardly one to object to pedantry, of course, but that in itself is not enough to push 2500 developers to use it.
Re: [PHP-DEV] Reviving scalar type hints
Larry, Assume for a moment that: - we tighten up the default passing rules, such that 32 passed to an int works but 32 footsteps errors (which I thing most are on board with doing) - we include a strict types mode as proposed, including the logical type widening cases - Zend Engine gets whatever static analysis tools you feel are appropriate. In what circumstances would I as a Drupal core developer (a few hundred thousand lines of code, need high degree of correctness, 2500 developers), contrib developer (a few thousand lines of code, medium correctness guarantee, 3 developers), or a client consultant (a few hundred lines of custom one-off code, 1 developer) want to enable strict mode? So, in what circumstances? Well, I think there are a few cases we need to talk about: In legacy systems (Wordpress, existing versions, etc): In these cases, strict mode would likely go in only extremely sensitive corners. So areas dealing with cryptography, random number generation, session security, etc. And it would go in slowly, as someone revamps it. Not all at once. Just like unit testing, scalar types would be refactored in very slowly, in the critical corners of legacy systems. It's unlikely that more than 1-2% of the entire system would ever become typed. In non-legacy systems it will likely come down to developer experience coupled with benefits of the tooling to the problem. A few hundred LOC script would likely never enable strict mode, and would be just fine because of it (you can mentally keep a few hundred LOC in your head at one time). The larger the project, the more the contributors, the more the benefits to using strict mode. That's not to say that large projects would immediately go full strict. It's just pointing out that the tradeoffs would need to be weighed by the authors. The proposals that Andrea and now I have put forward give the choice to the authors, and give the power to them. If they are not convinced to go strict, then they won't. And there's nothing wrong with that. But those who do want to go strict can. The real key that you should be thinking about is when errors are detected. The stricter the type system, the earlier the errors can be detected. In a lot of cases, a strict-mode type system can detect the vast majority (if not all) of type-related errors at compile time. That's a big benefit for large projects with many moving parts. Using strict typing would out more work on me. How much varies with the part of the application. (Closer to IO, more work.) Having it in the language means I will run into it sometime, even if not in code I originate. If potential performance is not a factor, then what is my carrot? What day to day benefit would I get from doing so other than pedantry?[1] You can infer things doesn't make it clear what the day to day impact is for me. Concrete examples, please. It's more work on you when you write a single line of code. It's less work when you're making a single line change in a 1-million-loc app. It's less work because the type system can verify that the change won't cause type errors when running (where even unit tests won't give you the same level of confidence). Beyond that, I'd highly recommend reading this article: http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-type-systems If it would only matter to the Facebook's of the world, well, they've got HACK already. How would this practically help Drupal, Symfony, Zend Framework, OwnCloud, Doctrine, phpMyAdmin, etc? Hack hasn't been out to the public for that long of a time, yet look at the buzz it's generating. Look at the frameworks that are popping up with it. Look at the libraries. I think if anything, the appearance of Hack (and its adoption) show that people want static typing, at least to some level... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/20/2015 09:39 AM, Anthony Ferrara wrote: I think if anything, the appearance of Hack (and its adoption) show that people want static typing, at least to some level... To be perfectly transparent here though, you should mention that your proposed RFC goes well beyond the strict typing that is in Hack because in Hack the internal API is largely untyped while your proposal is to default the entire internal API to strict types in strict mode. Also, in Hack there is a distinction between the off-line hh_client type-checker and the runtime. Hack examples all using ?hh // strict echo number_format('1000'); echo htmlspecialchars(1000); echo md5(1000); These are all fine both as far as the type-checker is concerned as well as the runtime, of course, but they are runtime fatals in your proposed RFC. And if you only go by the runtime and ignore the out-of-band type checker there are almost no strictness rules applied to the internal API in Hack. eg. explode(0, 1000); Here the hh_client type checker will complain that it is expecting strings, but the runtime will run it nicely. So when you say, and as I have heard other people say, that people want Hack-like strict typing, you have to be a bit careful about what is meant by that. Even in the cases where the internal API is typed in Hack, it is still not a runtime fatal if they are called with the wrong types. Now whether that is a good thing or not is debatable, of course, my point is simply that if you are going to use Hack adoption as a sign that people want static typing you should clearly explain that your approach is quite different from what Hack is doing. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Reviving scalar type hints
On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/20/2015 09:39 AM, Anthony Ferrara wrote: I think if anything, the appearance of Hack (and its adoption) show that people want static typing, at least to some level... To be perfectly transparent here though, you should mention that your proposed RFC goes well beyond the strict typing that is in Hack because in Hack the internal API is largely untyped while your proposal is to default the entire internal API to strict types in strict mode. Also, in Hack there is a distinction between the off-line hh_client type-checker and the runtime. This distinction is going away pretty soon. The typechecker is an integral part of Hack, and you shouldn't be able to ignore its errors. The runtime will soon consider them fatal errors too. If your code doesn't pass the hh_client typechecker, then its behavior when run on HHVM is completely undefined. Hack examples all using ?hh // strict echo number_format('1000'); echo htmlspecialchars(1000); echo md5(1000); These are all fine both as far as the type-checker is concerned as well as the runtime, of course, but they are runtime fatals in your proposed RFC.\ And they should be errors in Hack too. The reason they aren't are to ease transitions from PHP to Hack. I'd expect them to be more strongly typed eventually. And if you only go by the runtime and ignore the out-of-band type checker there are almost no strictness rules applied to the internal API in Hack. eg. explode(0, 1000); Here the hh_client type checker will complain that it is expecting strings, but the runtime will run it nicely. So when you say, and as I have heard other people say, that people want Hack-like strict typing, you have to be a bit careful about what is meant by that. Even in the cases where the internal API is typed in Hack, it is still not a runtime fatal if they are called with the wrong types. See above -- relying on (or even really thinking about) this distinction is relying on implementation details which are going to change. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Fri, Feb 20, 2015 at 9:26 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Anthony, On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote: hi Dmitry, On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. What is significant? Miracle ability of static analyzes for AOT? Please, can we discuss something without snark? And can we get past AOT? It's distracting. I only mentioned it here because I was specifically asked about it. It's not in my RFC. So please, let's get past it. sorry, I shouldn't be too emotional. actually, it's hard to express emotions with may bad English :) I think, you are doing a great job regarding AOT, but I think strict types won't help you a lot. We may discuss it out of the list on next week. if any place, on EFNet, if not the ML must remain the place to discuss things. I think we can agree on that, and we did as far as I can tell :) I didn't agree with you. Probably, I told that performance impact of run-time switch of type hinting semantic is slightly negative and it would be great to fix it if possible. Everyone is saying this shouldn't be voted on based on performance. You, me, Pierre, everyone. Performance is not a stopper for vote, but it doesn't mean it's not important. It is, only not in this context unless the patch changed in such ways that the performance impact becomes relevant. However, as of now, it is not. See Matt's perf results using the usual suspects. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Point of clarification: it exists in the RFC already: https://wiki.php.net/rfc/scalar_type_hints_v5#internal_functions_should_opt-in_to_typing On Fri, Feb 20, 2015 at 2:06 PM, Anthony Ferrara ircmax...@gmail.com wrote: Rasmus, To be perfectly transparent here though, you should mention that your proposed RFC goes well beyond the strict typing that is in Hack because in Hack the internal API is largely untyped while your proposal is to default the entire internal API to strict types in strict mode. Also, in Hack there is a distinction between the off-line hh_client type-checker and the runtime. In addition to what Josh said, I want to make one point here. This distinction is what lead me to push out 0.5 instead of where 0.4 was going. Let me explain: Let's say we don't type internal functions and release 7.1 with the rest of the dual mode type system. Then we're bound to never strictly type internal functions *unless* we introduce a NEW declare setting (declare(strict_types=2) or declare(internal_strict_types=1) or whatever). Which is a bit out there considering people already are testy about this one. So that practically means if we don't allow strict now, we can never tighten it again. However, if we do allow typed now, then we can expand and loosen in the future. If an API is found to be overly strict, it can be loosened (using a union type for example). We have the ability to loosen over time, but not strengthen. That's why I chose to apply the same typing to internal functions as user-land. To not to would be a major mistake IMHO. So that's why I'm moving forward with it. I will add this to discussion points in the RFC. So when you say, and as I have heard other people say, that people want Hack-like strict typing, you have to be a bit careful about what is meant by that. Even in the cases where the internal API is typed in Hack, it is still not a runtime fatal if they are called with the wrong types. Now whether that is a good thing or not is debatable, of course, my point is simply that if you are going to use Hack adoption as a sign that people want static typing you should clearly explain that your approach is quite different from what Hack is doing. It's not quite different. It's subtly different in a few details. But conceptually it's the same. Right, you are doing a gradual transition of an API that wasn't written to be strict. It was written with the assumption that type coercion would take place. If there is a good reason to ease the transition from PHP to Hack there is an even stronger reason to ease the transition from PHP to PHP. And that's why the current proposal has two modes: weak (coercive) and strict (error inducing). The default mode will not change things for anyone. Then they can start adding types, and things will just work. When they are ready, then they can turn on strict mode, one file at a time. Heck, they can run a strict-mode static analyzer on non-strict code to see where potential problems will be (assuming the analyzer has that mode) so they can fix it before committing to strict types in their production app. If that's not the definition of a gradual transition, I'm not sure what else can be done without fundamentally disallowing the ability to strictly type. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/20/2015 10:52 AM, Josh Watzman wrote: On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Hack examples all using ?hh // strict echo number_format('1000'); echo htmlspecialchars(1000); echo md5(1000); These are all fine both as far as the type-checker is concerned as well as the runtime, of course, but they are runtime fatals in your proposed RFC.\ And they should be errors in Hack too. The reason they aren't are to ease transitions from PHP to Hack. I'd expect them to be more strongly typed eventually. Right, you are doing a gradual transition of an API that wasn't written to be strict. It was written with the assumption that type coercion would take place. If there is a good reason to ease the transition from PHP to Hack there is an even stronger reason to ease the transition from PHP to PHP. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Reviving scalar type hints
Rasmus, To be perfectly transparent here though, you should mention that your proposed RFC goes well beyond the strict typing that is in Hack because in Hack the internal API is largely untyped while your proposal is to default the entire internal API to strict types in strict mode. Also, in Hack there is a distinction between the off-line hh_client type-checker and the runtime. In addition to what Josh said, I want to make one point here. This distinction is what lead me to push out 0.5 instead of where 0.4 was going. Let me explain: Let's say we don't type internal functions and release 7.1 with the rest of the dual mode type system. Then we're bound to never strictly type internal functions *unless* we introduce a NEW declare setting (declare(strict_types=2) or declare(internal_strict_types=1) or whatever). Which is a bit out there considering people already are testy about this one. So that practically means if we don't allow strict now, we can never tighten it again. However, if we do allow typed now, then we can expand and loosen in the future. If an API is found to be overly strict, it can be loosened (using a union type for example). We have the ability to loosen over time, but not strengthen. That's why I chose to apply the same typing to internal functions as user-land. To not to would be a major mistake IMHO. So that's why I'm moving forward with it. I will add this to discussion points in the RFC. So when you say, and as I have heard other people say, that people want Hack-like strict typing, you have to be a bit careful about what is meant by that. Even in the cases where the internal API is typed in Hack, it is still not a runtime fatal if they are called with the wrong types. Now whether that is a good thing or not is debatable, of course, my point is simply that if you are going to use Hack adoption as a sign that people want static typing you should clearly explain that your approach is quite different from what Hack is doing. It's not quite different. It's subtly different in a few details. But conceptually it's the same. Right, you are doing a gradual transition of an API that wasn't written to be strict. It was written with the assumption that type coercion would take place. If there is a good reason to ease the transition from PHP to Hack there is an even stronger reason to ease the transition from PHP to PHP. And that's why the current proposal has two modes: weak (coercive) and strict (error inducing). The default mode will not change things for anyone. Then they can start adding types, and things will just work. When they are ready, then they can turn on strict mode, one file at a time. Heck, they can run a strict-mode static analyzer on non-strict code to see where potential problems will be (assuming the analyzer has that mode) so they can fix it before committing to strict types in their production app. If that's not the definition of a gradual transition, I'm not sure what else can be done without fundamentally disallowing the ability to strictly type. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Thursday, February 19, 2015 9:00 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints On 02/17/2015 01:30 PM, Zeev Suraski wrote: Yes, I already know that. At this point, if I could rephrase the camps a bit I see two different sets of priorities: 1) PHP should do what seems obviously safe to do, to make life easiest for developers. That is, it's patently obvious that 32 and 32 are equivalent, so don't make developers worry about the distinction because to them there isn't one. This is an entirely reasonable position. 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with compile- time-knowlable information could be written and even incorporated into future versions of PHP without API breaks. (I think Anthony demonstrated earlier examples of function calls no longer being slow, for instance, if the type juggling could be removed at compile time.) This is an entirely reasonable position. Larry, There's actually very little difference between coercive type hinting and strict type hinting in terms of performance. If you read what both Dmitry and Anthony said, it should be clear that the vast majority of gains can be had even without any sort of type hinting at all - and as Stas pointed out, JavaScript has some mind blowing JIT optimizations without any explicit type info at all. Moreover, I think it's easy to lose the forest from the trees here, by focusing on a very narrow piece of code - without looking at the bigger picture. Ultimately, if you have a piece of data that you want to pass from a caller to a callee, it could be under one of three labels: 1. A piece of data the callee can use as-is. 2. A piece of data the callee can use after conversion (be it explicit or implicit). 3. A piece of data the callee cannot/shouldn't use. When comparing strict and coercive type hints, there's no difference between them in terms of #1; There's a subtle difference with #3 - but only in the error situation. In other words, for coercive type hints, it would just take a bit more time before they fail, because they have to conduct a few more checks. However, that's an error situation anyway, which is either already going to bail out, or go through error handling code - which would be very slow anyway. So focusing on #2, in a practical real world situation - the difference is actually a lot more subtle than people might think if they only zoom into on the area around parameter passing. The bigger picture is, what would the code author - the one making the call - want to do, semantically? In other words, if you have 32 coming from a database or whatnot, are you likely to want an API that accepts an int to be able to use that? I think the answer is almost always yes. So practically, what will happen with strict typing is that you'd explicitly cast it to int, while with coercive typing - you'd rely on the language to do it for you. Arguably, very little difference between the two in terms of performance. Note that it's possible people will be able to come up with various edge cases where strict typing might somehow alert you to a situation that may push you to change your code in a way it might end up being slightly faster. But those will be edge cases and should be taken in the context - in the vast majority of code patterns, there's zero difference between the two approaches in terms of performance. In terms of functionality, however, there's actually a substantial difference between the two - explicit casting is a lot more aggressive than the coercion rules we're thinking about for coercive type hints. It'll happily and silently coerce Apple into 0, 100 dogs into 100, and 3.1415 into 3. Now, diving back to future potential AOT/JIT, it's simply not true that there's any gain at all from strict typing - or at least, neither Dmitry (who wrote a full JIT compiler for PHP that runs Mandelbrot as fast as gcc does) nor me were able to understand them. Anthony spoke about being able to completely eliminate the zval container and all associated checks, so that in certain situations you'd be able to map a PHP integer all the way down to a C (or asm) integer. That can certainly be done, but it has nothing to do with strict vs. coercive type hints. Here's why: 1. At this point I think it's clear to everyone that inside the called function, there's zero difference between strict and coercive typing (or even the weak typing we were talking about earlier). They're 100% guaranteed to receive what they asked, either because values were coerced or blocked from even making it into the function. 2. On the outside calling code - if you can conduct the level of type inference that would enable you to safely compile
Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 09:13, Zeev Suraski wrote: Obviously, I think 'weak' campers have a lot to gain too - by making sensible conversions work fine as expected, without having to resort to explicit casts. And everyone stands to gain from having just one mode, instead of two. The coercive typing approach would require each camp to give up a bit of their 'ideology', but it also gives both schools of thought *most* of what they want, including the key tenets for each camp (rejecting non-sensible conversions - always, allowing sensible ones - always). I believe that's what makes it a good compromise, a better one than the currently proposed RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Hi Lester, I didn't add restrictions specific to number representation in the draft ruleset yet, becausen while I think that's an important point, I didn't have time to study it in depth. I know you're an expert on this as you continuously (rightly) raised the point. So, can you elaborate on this and send me or, better, publish on the list the detailed set of changes you suggest, including 32 bit vs 64 bit concerns if they fit. Today, conversion restrictions are rather limited as floats which don't fit in int give 0, and int to float is considered as always possible. I mean that must be technically incorrect, while unnoticed in the vast majority of cases. So can you write a consistent set of changes you would introduce ? Thanks François -Message d'origine- De : Lester Caine [mailto:les...@lsces.co.uk] Envoyé : jeudi 19 février 2015 11:24 À : internals@lists.php.net Objet : Re: [PHP-DEV] Reviving scalar type hints On 19/02/15 09:13, Zeev Suraski wrote: Obviously, I think 'weak' campers have a lot to gain too - by making sensible conversions work fine as expected, without having to resort to explicit casts. And everyone stands to gain from having just one mode, instead of two. The coercive typing approach would require each camp to give up a bit of their 'ideology', but it also gives both schools of thought *most* of what they want, including the key tenets for each camp (rejecting non-sensible conversions - always, allowing sensible ones - always). I believe that's what makes it a good compromise, a better one than the currently proposed RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Lester Caine [mailto:les...@lsces.co.uk] Sent: Thursday, February 19, 2015 12:24 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints On 19/02/15 09:13, Zeev Suraski wrote: Obviously, I think 'weak' campers have a lot to gain too - by making sensible conversions work fine as expected, without having to resort to explicit casts. And everyone stands to gain from having just one mode, instead of two. The coercive typing approach would require each camp to give up a bit of their 'ideology', but it also gives both schools of thought *most* of what they want, including the key tenets for each camp (rejecting non-sensible conversions - always, allowing sensible ones - always). I believe that's what makes it a good compromise, a better one than the currently proposed RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/19/2015 04:13 AM, Zeev Suraski wrote: -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Thursday, February 19, 2015 9:00 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints On 02/17/2015 01:30 PM, Zeev Suraski wrote: Yes, I already know that. At this point, if I could rephrase the camps a bit I see two different sets of priorities: 1) PHP should do what seems obviously safe to do, to make life easiest for developers. That is, it's patently obvious that 32 and 32 are equivalent, so don't make developers worry about the distinction because to them there isn't one. This is an entirely reasonable position. 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with compile- time-knowlable information could be written and even incorporated into future versions of PHP without API breaks. (I think Anthony demonstrated earlier examples of function calls no longer being slow, for instance, if the type juggling could be removed at compile time.) This is an entirely reasonable position. Larry, There's actually very little difference between coercive type hinting and strict type hinting in terms of performance. If you read what both Dmitry and Anthony said, it should be clear that the vast majority of gains can be had even without any sort of type hinting at all - and as Stas pointed out, JavaScript has some mind blowing JIT optimizations without any explicit type info at all. Moreover, I think it's easy to lose the forest from the trees here, by focusing on a very narrow piece of code - without looking at the bigger picture. Ultimately, if you have a piece of data that you want to pass from a caller to a callee, it could be under one of three labels: 1. A piece of data the callee can use as-is. 2. A piece of data the callee can use after conversion (be it explicit or implicit). 3. A piece of data the callee cannot/shouldn't use. When comparing strict and coercive type hints, there's no difference between them in terms of #1; There's a subtle difference with #3 - but only in the error situation. In other words, for coercive type hints, it would just take a bit more time before they fail, because they have to conduct a few more checks. However, that's an error situation anyway, which is either already going to bail out, or go through error handling code - which would be very slow anyway. So focusing on #2, in a practical real world situation - the difference is actually a lot more subtle than people might think if they only zoom into on the area around parameter passing. The bigger picture is, what would the code author - the one making the call - want to do, semantically? In other words, if you have 32 coming from a database or whatnot, are you likely to want an API that accepts an int to be able to use that? I think the answer is almost always yes. So practically, what will happen with strict typing is that you'd explicitly cast it to int, while with coercive typing - you'd rely on the language to do it for you. Arguably, very little difference between the two in terms of performance. Note that it's possible people will be able to come up with various edge cases where strict typing might somehow alert you to a situation that may push you to change your code in a way it might end up being slightly faster. But those will be edge cases and should be taken in the context - in the vast majority of code patterns, there's zero difference between the two approaches in terms of performance. In terms of functionality, however, there's actually a substantial difference between the two - explicit casting is a lot more aggressive than the coercion rules we're thinking about for coercive type hints. It'll happily and silently coerce Apple into 0, 100 dogs into 100, and 3.1415 into 3. Now, diving back to future potential AOT/JIT, it's simply not true that there's any gain at all from strict typing - or at least, neither Dmitry (who wrote a full JIT compiler for PHP that runs Mandelbrot as fast as gcc does) nor me were able to understand them. Anthony spoke about being able to completely eliminate the zval container and all associated checks, so that in certain situations you'd be able to map a PHP integer all the way down to a C (or asm) integer. That can certainly be done, but it has nothing to do with strict vs. coercive type hints. Here's why: 1. At this point I think it's clear to everyone that inside the called function, there's zero difference between strict and coercive typing (or even the weak typing we were talking about earlier). They're 100% guaranteed to receive what they asked, either because values were coerced or blocked from even making it into the function. 2. On the outside calling code - if you can conduct the level of type inference that would enable you
Re: [PHP-DEV] Reviving scalar type hints
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. So that means one less branch (no guard) per argument per function call. In addition, native calls can be used in a lot of cases, which means the compiled code doesn't even need to know about a zval (significant memory and access reduction). This has potential to be significant. Not to mention the other optimizations that are possible. This already worked for as without type hinting. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic just to get few unit tests out of the box. Thanks. Dmitry. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Thu, Feb 19, 2015 at 8:21 AM, Lester Caine les...@lsces.co.uk wrote: On 19/02/15 12:52, Zeev Suraski wrote: Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. This still leaves the 'black hole' caused by the fact that databases are actively using 'BIGINT' even on 32 bit platforms. It may be that the only practical approach is gmp, but using that and writing code that selects that on a 32bit platform, then switching to clean 64bit maths on a 64bit platform does not sound like simplifying things? As with other debates, some say ignore 32 bit, and others say lets loose the constraints altogether, but having a fundamental type behave differently depending on platform is a problem? Lester, You keep coming with this topic in every possible threads. As I understand that DB interactions are some of the primary usages of PHP, this discussion has nothing to do with that. DB drivers will do what they have to do to deal with PHP DB types, as they always do. It would be very good if you could focus on the actual content of a RFC or discussion instead. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 12:52, Zeev Suraski wrote: Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. This still leaves the 'black hole' caused by the fact that databases are actively using 'BIGINT' even on 32 bit platforms. It may be that the only practical approach is gmp, but using that and writing code that selects that on a 32bit platform, then switching to clean 64bit maths on a 64bit platform does not sound like simplifying things? As with other debates, some say ignore 32 bit, and others say lets loose the constraints altogether, but having a fundamental type behave differently depending on platform is a problem? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 12:47, François Laupretre wrote: I didn't add restrictions specific to number representation in the draft ruleset yet, becausen while I think that's an important point, I didn't have time to study it in depth. I know you're an expert on this as you continuously (rightly) raised the point. So, can you elaborate on this and send me or, better, publish on the list the detailed set of changes you suggest, including 32 bit vs 64 bit concerns if they fit. Today, conversion restrictions are rather limited as floats which don't fit in int give 0, and int to float is considered as always possible. I mean that must be technically incorrect, while unnoticed in the vast majority of cases. So can you write a consistent set of changes you would introduce ? François ... My main interest in this over the years has been while trying to port data between different engines, and that includes porting legacy data from older systems such as dbase some of which originates from 8 bit processor days. One area that overlays the general discussion is the simple size of a scalar value, and this just mirrors the number of bytes used to store it. I1, I2, I4 and I8, but a more general validation facility on top of 'integer' would be a simple range. decimal or numeric and float may get lumped together, but integer is a much better base for decimal/numeric since it is lossless and simply moves the position of the decimal point. Storage only requires an integer of the appropriate size for the number of digits. float is another miss used definition since it normally only allows for 32 bits of data, while double expands that to 64 bits. So once again the platform may affect how these values are processed. Pierre - You may think that the size of integer is irrelevant in the discussion on providing a strict type use of it, but in practice it is somewhat important if the codebase you are creating is only 32bit but all the data being handled is 64bit. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Hi Larry, Thanks for trying to sort this out. This is very valuable work. De : Larry Garfield [mailto:la...@garfieldtech.com] Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? I will let Anthony reply as the question is for him, but can you precide which compiler you're talking about ? The compiler layer of the PHP interpreter, or a future AOT compiler generating native executable code from PHP code ? I guess the reply will be different in both cases. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. So that means one less branch (no guard) per argument per function call. In addition, native calls can be used in a lot of cases, which means the compiled code doesn't even need to know about a zval (significant memory and access reduction). This has potential to be significant. Not to mention the other optimizations that are possible. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi! So let's talk compromise. Would leaving internal functions out of the picture at this stage change you mind? This is effectively what Hack does, internal functions are explicitly marked as coercible. For me, the option that makes users remember which functions are internal and which are not, because they work radically different (and I don't mean in some small detail, I mean up to a complete failure if I get it wrong) is not something I'd really like. Would a tri-state option make sense? ('weak-all', 'strict-user/weak-internal', 'strict-all') How do we get from here to something you would like? Two semantics in the same language are bad enough. Three, IMHO, is just a no go, dealing with code having three different semantics would be completely impossible. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 12:48 AM, Sara Golemon wrote: Don't mistake me for hack. -Sara No one could ever mistake you for a hack, Sara. :-) --Larry Garfield (Sorry, it was just sitting there...) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote: Yes, I already know that. The difference, and why I keep pointing that out, is that me and many others want strict typing for our own reasons (but still in its entirety instead of as a limited mode) and most of us don't even care if you getting weak typing for your own usage. You can't work towards consensus if your target is to prevent the opposing group of getting what they want. I see both as valuable tools for different jobs and I want to have more tools at my disposal, while you're trying to tell me that I should use only one tool for everything. First, it's very important to understand that my target is to prevent the opposing group from getting what they want. I'm really not sadistic :) My reasons were obviously different and worked towards a different goal. Much in the same way that people who vote against an RFC - one of the countless that were voted against - don't do that to hurt the ones who support it. They do it because they think adding it would bring negative consequences. I never believed the 'You don't have to use it' as a silver bullet explanation for why it's OK to add features with potentially negative implications. The good news is that I think that in many ways the ideas we're toying with right now are better for the strict-type camp, especially if we end up going for just one mode, and meet roughly mid-way in terms of strict and weak - which I think is doable. The biggest gripes strict campers had with weak mode are gone in this proposal, and unlike v0.3 - that would actually be the default (and only) behavior, which is a big gain for the strict campers. And the most prominent features of weak typing are kept (dynamic type conversion where it makes sense), hopefully making the weak campers happy too. But you implied that most objections were from people who don't want strict typing in PHP at all. And I disagree with that because it's a speculation, which in turn you are using to favor your weak-hints-only case (hence, twisting it in another direction). I didn't imply it now (at least I certainly didn't intend to). I did outright say it a week or two ago, and still believe that's the case but reached the conclusion that none of us would gain anything from further discussing it. We won't know unless we start actually polling the people who voted and ask, which we're not going to do, and we're obviously not going to convince each other. Much more importantly, it at least *seems* as if we have a direction for something that a very wide audience may rally behind. Let's focus on that! Zeev At this point, if I could rephrase the camps a bit I see two different sets of priorities: 1) PHP should do what seems obviously safe to do, to make life easiest for developers. That is, it's patently obvious that 32 and 32 are equivalent, so don't make developers worry about the distinction because to them there isn't one. This is an entirely reasonable position. 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with compile-time-knowlable information could be written and even incorporated into future versions of PHP without API breaks. (I think Anthony demonstrated earlier examples of function calls no longer being slow, for instance, if the type juggling could be removed at compile time.) This is an entirely reasonable position. Naturally those two positions are mutually exclusive; if the compiler has to allow for 32 to be converted to 32 at runtime, it can't optimize the opcodes by removing the code that would do that conversion! I was against the mixed-mode approach before, but I given the above I am warming to it. The trade off here is between DX (in the sense of the code doing what I mean and not babysitting type information) and potential performance and bug-finding benefits. Different places in an application may need different trade-offs. In practice, the closer you are to an IO action (browser input, database, file, etc.) the more you want the obviously safe behavior; once you pass one layer of specified typing you can be pretty confident that strict checks will just work from there on out. In essence, opt-in-strict becomes an opt-in compiler, be pedantic so you can make my code faster flag. More carrot than stick, since people can control when they opt-in to fancier compiler optimizations at the cost of some DX, but only in some cases. I started this email planning to ask Anthony how flexible strict checking could get without losing the benefits of it, but I think I've just convinced myself the answer is not very. Which then leaves only the question of internal functions that Rasmus raised, which... it looks like is discussed in later emails so I will try to catch up on those. :-) --Larry Garfield -- PHP Internals - PHP
Re: [PHP-DEV] Reviving scalar type hints
Hi! 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with Is that really the case? Javascript has very good optimizing engine, and Javascript has no typing. Of course, it is probably *easier* with strict types, but harder and impossible are two very different things. In fact, I do not see large benefits for static analysis from scalar typing - execution path rarely is different depending on if something is integer or string, except for obvious is_* check - but those are rarely controlling any useful logic. It may be different depending on if it's a scalar or an object - but that we already have covered. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 3:30 AM, Leigh lei...@gmail.com wrote: On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote: We can sigh and tut about this not being the PHP way, but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who should have that authority over their own application. I find this view way too extreme. You find giving authority over an application to the application author too extreme? And you find taking authority over a library away from the library author completely acceptable? I'm not suggesting taking authority of the library away from its author, so you question is invalid. If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? This RFC allows you to turn on strict for your library. What it doesn't do is allow you to turn on strict for the calling application. What's yours is yours, what's theirs is theirs. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski z...@zend.com wrote: On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote: Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote: If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. I agree that it doesn't give everybody what they want - it only gave weak hint supporters *all* that they want. Andrey, I'm a weak typing supporter; I want PHP to never make it easy at the language level to treat 32 and 32 differently; The RFC did exactly that. Yes, I already know that. The difference, and why I keep pointing that out, is that me and many others want strict typing for our own reasons (but still in its entirety instead of as a limited mode) and most of us don't even care if you getting weak typing for your own usage. You can't work towards consensus if your target is to prevent the opposing group of getting what they want. I see both as valuable tools for different jobs and I want to have more tools at my disposal, while you're trying to tell me that I should use only one tool for everything. - The v0.3 RFC didn't give weak hint supporters everything they wanted. QED. Many also objected because strict typing was only opt-in and could never affect the caller's code unless the caller explicitly declares that they want to do that. You're ignoring that and you're twisting it the other way around. It's enough to provide one counter example to disprove an assertion - the assertion that the v0.3 RFC gave everyone what they wanted - and I provided the one I can personally attest to. I certainly didn't claim strict typing supporters got everything they wanted, so I'm not sure why I'm twisting anything. If anything, you're only making the point that the v0.3 RFC doesn't give everyone what they want stronger. Yes, I am making the point stronger. But you implied that most objections were from people who don't want strict typing in PHP at all. And I disagree with that because it's a speculation, which in turn you are using to favor your weak-hints-only case (hence, twisting it in another direction). I think the options we're discussing here take us away from this zero sum game, provides benefits to both schools of thought, and it seems to me as if you were open to it. I'd much rather we invested our energies there! Zeev Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 15:30, François Laupretre wrote: Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? You didn't read it right. I was talking of conversions *from* bool, not *to* bool. (int - bool) is fine and will be preserved, but I propose to remove (bool - int). You will still return numbers as bool, and non-zero will still be converted to true. Relax :) My current practice up until now has been to use 'return false' when an action failed, but the main return would be a number of records or string of data. So you are now blocking that activity ... I'm reading to right, but you are not thinking all possibilities through. But I think I'm starting to see it broken already with the other changes to the core :( I'm not returning 'IS_FALSE' so I'm probably going to have to change the 'false' to '0' anyway so as to avoid the bool? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 15:47, Anthony Ferrara wrote: A static analyzer (one of the reasons people want strict) would error there. The reason is that *at compile time* it can't reason about the code well enough to determine if there's an error or not. You're passing a string where you expect an int. Is that going to work? We don't know. So the analyzer would need to throw a warning that the cast is potentially unsafe because it can't guarantee that the runtime won't throw an error. Which means that to remove the warning you'd need to add an explicit cast. This is what I do not get ... I have no idea what string will be provided, so either we get a valid number or we don't. Conversion of the string to a number needs to follow several rules such as thousand divider or decimal point, or perhaps even spelt out numbers. If the input string can't be converted to a number then we need the error message - explicit casting fixed nothing - you can't eliminate the error if the passed string can't be converted so you need an alternate escape route. A generic 'type fault' does not help since you want to return the fault to the inputting source? Static analysis only works if you assume there is no human involvement in the generation of the inputs? Now if you are handling the problem of mistakes in the input prior to the function call you already know that the data is good so why do you need 'strict' at all. You will process the string, decide if you want to tell the client that it must be a whole number, or if it exceeds some limit. That may even be done in javascript in the browser, so what is fed back has already been sanitised. It will come in as a string and you know it is a valid number ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/2015 15:47, Anthony Ferrara wrote: If we want to add a numeric type as a virtual union of int and float, that's one way to solve the concern. If we don't, we could also allow widening primitive conversion (int - float). That wouldn't work well with bigints, but would be fine in other cases. But there are plenty of languages that always require explicit type conversion. So even if we choose that, we're in good company. As far as I understand, allowing int - float would help fix a few of Rasmus' (or was it Benjamin?) concerns about things like sin() requiring floats in strict mode. It would make strict mode a lot more usable with C code as well. +1 on keeping the strictness benefits and remove some of the drawbacks. Having numeric in addition might be nice mostly for return values I guess, but it seems a bit redundant to me if int - float is allowed. As for the straw poll, I also think declare() is the clearest syntax, especially if it's enforced to appear at most once and on top of the file to remove any potential misuses. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/16/2015 09:48 PM, Sara Golemon wrote: Second, I should clarify that while the HHVM runtime performs coersion, the hack type checker is strict. So my original statement was inaccurate. As far as hack is concerned, it's simply strict. Period. With both the default (partial) type checking and strict enabled, my number_format() example in Hack produces: ... Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate: hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ., $thousands_sep = ,); We left a lot of stuff untyped from hack's point of view precisely because so much of PHP's APIs are non-sensical. Have you looked at what chr() does with bad types lately? Yikes. So, you keep asking what I would support. I would like to see an RFC along the following lines: 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. Hopefully, though I think that we could embrace the idea of trailing space as insignificant. 2a. In strict mode, tone down the strictness and allow non-lossy coercion including int-float. And yes, I know in really edge cases that isn't technically non-lossy, but for all practical purposes it is. Nod. Ze'ev called for this too. 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type numeric string. 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP to implement a stricter curl_setopt(), for example. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote: Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote: If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. I agree that it doesn't give everybody what they want - it only gave weak hint supporters *all* that they want. Andrey, I'm a weak typing supporter; I want PHP to never make it easy at the language level to treat 32 and 32 differently; The RFC did exactly that. - The v0.3 RFC didn't give weak hint supporters everything they wanted. QED. Many also objected because strict typing was only opt-in and could never affect the caller's code unless the caller explicitly declares that they want to do that. You're ignoring that and you're twisting it the other way around. It's enough to provide one counter example to disprove an assertion - the assertion that the v0.3 RFC gave everyone what they wanted - and I provided the one I can personally attest to. I certainly didn't claim strict typing supporters got everything they wanted, so I'm not sure why I'm twisting anything. If anything, you're only making the point that the v0.3 RFC doesn't give everyone what they want stronger. I think the options we're discussing here take us away from this zero sum game, provides benefits to both schools of thought, and it seems to me as if you were open to it. I'd much rather we invested our energies there! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Andrey Andreev [mailto:n...@devilix.net] If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. And that brings us back to square one ... Expose only 1 tool to userland, but then give two options to the much less-populated crowd of extension developers. That doesn't make sense to me. I must say 'no'. That's completely different of dual-mode, as it was not clear, but the types we would add to ZPP would be also available in userland. The objective is to maintain a full consistency between userland, internal funcs, and documentation. This is so true that we'll probably, in the future, introduce ZPP supported specialized types, like path, to userland. I am also quite sure that we'll add a set of strict types, for the few cases where zval type *really* matters (like sorting and other 'special' stuff). But we are not intending to make it more complex than needed for a first release. We all need to practice before identifying additional needs. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, February 17, 2015 5:48 PM To: Zeev Suraski Cc: franc...@php.net; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints Zeev et al, Because it **wasn't** a compromise (neither side had to give up anything). It gave both sides exactly what they want and need while letting them work together transparently. If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. It's not unique to this RFC either; There's a reason we don't accept all proposals, including countless ones that have zero compatibility/performance issues, just because we don't think they're a good fit for the language. Regarding your point about static analyzers, based on what I saw on this list it hardly seems that this is the main reason most proponents of strict types are interested in them. I, for one, think developer productivity is a lot more important than making life easy for static analyzers, and static analyzers should be designed around the language, not vice versa. I urge you to consider the fact that the solution that 'gives everyone what they wanted' is hardly that at all, and we're trying to find a potential compromise that will hopefully have a lot fewer people objecting to it. If we succeed, not everyone will get everything they want, but hopefully a lot more people will be able to join the yes vote. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon poll...@php.net wrote: On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/16/2015 09:48 PM, Sara Golemon wrote: Second, I should clarify that while the HHVM runtime performs coersion, the hack type checker is strict. So my original statement was inaccurate. As far as hack is concerned, it's simply strict. Period. With both the default (partial) type checking and strict enabled, my number_format() example in Hack produces: ... Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate: hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ., $thousands_sep = ,); We left a lot of stuff untyped from hack's point of view precisely because so much of PHP's APIs are non-sensical. Have you looked at what chr() does with bad types lately? Yikes. Wait, so Hack is actually only treating userland functions strict (and maybe the occasional internal function). This approach would immediately fix all the number_format, sin, tan problems, but again be rejected by static propononets for not being complete for analysis. We can run this circle for another time :-) So, you keep asking what I would support. I would like to see an RFC along the following lines: 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. Hopefully, though I think that we could embrace the idea of trailing space as insignificant. 2a. In strict mode, tone down the strictness and allow non-lossy coercion including int-float. And yes, I know in really edge cases that isn't technically non-lossy, but for all practical purposes it is. Nod. Ze'ev called for this too. 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type numeric string. 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP to implement a stricter curl_setopt(), for example. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 08:38 AM, Sara Golemon wrote: On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate: hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ., $thousands_sep = ,); Right, so most of the internal API functions were omitted from strict typing in Hack it looks like except for some places where it made sense to selectively apply stricter checks. The RFC as it stands doesn't give us this option which is my major problem with it. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... Yes, something along those lines to allow gradual and selective strictness. The internal/extension api is just another library and the authors of these library functions should have the same allowance as userspace library authors. Like you said in one reply, What's yours is yours, what's theirs is theirs. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, February 17, 2015 5:48 PM To: Zeev Suraski Cc: franc...@php.net; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints Zeev et al, Because it **wasn't** a compromise (neither side had to give up anything). It gave both sides exactly what they want and need while letting them work together transparently. If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. I agree that it doesn't give everybody what they want - it only gave weak hint supporters *all* that they want. Many also objected because strict typing was only opt-in and could never affect the caller's code unless the caller explicitly declares that they want to do that. You're ignoring that and you're twisting it the other way around. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Am 17.02.2015 um 12:30 schrieb Leigh: And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? As the library author you will never ever notice if your library was called in strict mode or not! And that is the point: you will not get any gain from making all your parameters strict, you will just force the user to cast (as Rasmus said already). Repeating that strict mode is required from a library author's point of view does not make it right. You always get the types you want, you just limit the library consumer. But you may want your code call other functions in strict mode to catch some type errors, that is perfectly valid, I don't deny that. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Zeev Suraski [mailto:z...@zend.com] Even though that's not what I meant when I sent my proposal in the morning, Sorry, I was not clear enough : it was my position only. I've been wondering about the same thing (also with the feedback from Dmitry). Can go an extra step from both directions, and come up with a rule set that is stricter than the currently proposed weak hinting, but not as strict as the currently proposed strict hinting? Key challenge I see with that is that scalar type hinting would go farther apart from our implicit casting rules. However, the current RFC already aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting Apple as an int). Choosing between that and having two separate modes, I think that's the better option. ZPP already chose a while ago to implement a much restricted conversion set from convert_to_xxx() rules. The objective is not the same, as casting must be as permissive as possible (we could discuss that in the future too...). I hope we all agree to keep scalar type hinting aligned on ZPP rules. I also think we all agree, while implicitely, on the ruleset changes we're expecting. I am currently writing this down, so that we have a written base to discuss. Just one detail, to be sure we are in sync : new conversion rules will remain in sync between zend_parse_parameters() and zpp, while future additional types will be defined in zpp only. I assume we are OK to refuse extending the zend_parse_parameters() format in the future. I think that practically speaking, that is incorrect, at least from my experience with PHP developers. They do differentiate between built-in functions and userland functions. There are some fundamental differences between the two (being able to find their code, step into them in a debugger, find docs on php.net, etc.). As I mentioned earlier, the fundamental difference between built-in functions and userland functions in the context of our discussion is that if we introduce userland type hints, nothing happens before people change their code, and make (hopefully) informed decisions about what type hints to add, if any. No such luck with built-in functions, which have type information associated, built collectively over the last two decades. As Rasmus demonstrated, flipping that switch on for built-in functions results in a lot of work to 'clean' the code up, but you end up with having code that's not necessarily any better. That said, it's quite possible that the situation will be much improved if when we implement the less-strict rules we're proposing here, which would accept 32 as an integer or 37 as a float. I fully agree with you and Rasmus. Strict typing, as defined in 0.3, does not fit with internal functions. To summarize, we have two options : - differentiate behavior and run weak checks on internal functions, even if strict switch is on. - attempt to get back to a single-mode mechanism, which would keep both worlds in sync. I definitely prefer to explore the second one. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, Why not, but let's first try avoiding it first, as we'll bikeshed during weeks on the syntax for new keywords. Remember that class names share the same naming space as type hint keywords. So, defining new keywords will lead to endless discussions. And stating, as I heard, that we just have to use lowercase-only keywords, is not serious. That's a little off-topic here, but I would also propose to deprecate using bare class names as type hints from 7.0. That's a big BC change and a lot will hate that, but the issue was created when the 'array' type hint was added, and we need to fix it (proposing an alternate syntax like 'object(classname)'). As long as we support bare class names, adding a new type is almost impossible and typedef is *totally* impossible. It's just deprecating, but the impact is such that it can come with a major version only. A smoother path can be to introduce the alternate syntax in 7.0, then deprecate in 7.1 or 7.2. It will take more time but it's probably better. union types can be kept for the future if we don't go the nullable road, as it would be too confusing making 'string|null' and '?string' synonyms. I think we all agree about that. Fine :) ! Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 5:02 PM, Dennis Birkholz den...@birkholz.biz wrote: Am 17.02.2015 um 12:30 schrieb Leigh: And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? As the library author you will never ever notice if your library was called in strict mode or not! And that is the point: you will not get any gain from making all your parameters strict, you will just force the user to cast (as Rasmus said already). Repeating that strict mode is required from a library author's point of view does not make it right. You always get the types you want, you just limit the library consumer. But you may want your code call other functions in strict mode to catch some type errors, that is perfectly valid, I don't deny that. What you've said has been repeat tens of times already. Many of us just disagree with that rationale, because it's missing the point. Nobody is stupid enough not to know that they always receive the specified type. There's just a big difference between knowing that you will receive a i.e. boolean, and knowing that the user *passed* a boolean. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 14:49, Andrey Andreev wrote: I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Agreed as well. However, while bool - int conversion one of the reasons why many people want strict type-hints, it also often makes sense and is quite widespread. There's no silver bullet for that problem. Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? It is also why some of the other 'little changes' such as hard coded IS_TRUE and IS_FALSE are actually somewhat alien! Certainly is does not play well with my methods of working, but then I prefer a function to return a result rather than crash out with an exception ... Although -ve values are even more useful than a simple 'zero' return and that may replace a string return. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 1:30 PM, Leigh lei...@gmail.com wrote: On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote: We can sigh and tut about this not being the PHP way, but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who should have that authority over their own application. I find this view way too extreme. You find giving authority over an application to the application author too extreme? And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? I'm sure I could find a way of detecting non-strict mode and throw a fatal, or force access through a facade/wrapper of some sort where I've turned on strict and made myself the caller. Isn't this equally unhelpful? The point is some people will want strict turned on, and they will find ways to force it on people. You're going to have to live with it, so just make it a possibility from the outset. ^ That. I've said the same thing multiple times already. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: François Laupretre [mailto:franc...@php.net] Sent: Tuesday, February 17, 2015 2:58 PM To: 'Sara Golemon'; 'Zeev Suraski' Cc: 'PHP internals' Subject: RE: [PHP-DEV] Reviving scalar type hints 2. It is not not about being lossless or not. People expect bool - int to be disabled, for example, and it is not lossless. 3. It is more a question of finding a consensus about conversions which don't make sense, and disabling them. Examples include bool conversion to any other type and, of course, disabling trailing chars in numeric strings. I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Agreed as well. However, while bool - int conversion one of the reasons why many people want strict type-hints, it also often makes sense and is quite widespread. There's no silver bullet for that problem. 4. Once this is done, 99% of strict type proponents already said they would be OK with the so-called (not so) weak mode, making it possible to get rid of this far from perfect two-mode mechanism (actually, this two-mode approach more and more reminds me a great idea about bringing transparent Unicode support in PHP). Even though that's not what I meant when I sent my proposal in the morning, I've been wondering about the same thing (also with the feedback from Dmitry). Can go an extra step from both directions, and come up with a rule set that is stricter than the currently proposed weak hinting, but not as strict as the currently proposed strict hinting? Key challenge I see with that is that scalar type hinting would go farther apart from our implicit casting rules. However, the current RFC already aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting Apple as an int). Choosing between that and having two separate modes, I think that's the better option. I don't think it has 99% support, but surely better than the dual-mode approach indeed. But is it the best solution? The dual-mode approach was suggested because there is need and demand for *two* kinds of type-hinting. Most of the controversy and criticism came from the fact that introduces a switchable mode, while most of the praise received was due to somebody finally proposing *both* solutions at the same time. * Exclude internal functions from the strict switch. (Perhaps have a separate switch for internal functions at a later date) This would make the feature inconsistent from an end user's pov. If a user enables strict mode, he assumes strict checks for every function he calls. *We* know that userspace and internal functions use different mechanisms, but the end user doesn't have to know. From his pov, a function is a function. I think that practically speaking, that is incorrect, at least from my experience with PHP developers. They do differentiate between built-in functions and userland functions. There are some fundamental differences between the two (being able to find their code, step into them in a debugger, find docs on php.net, etc.). As I mentioned earlier, the fundamental difference between built-in functions and userland functions in the context of our discussion is that if we introduce userland type hints, nothing happens before people change their code, and make (hopefully) informed decisions about what type hints to add, if any. No such luck with built-in functions, which have type information associated, built collectively over the last two decades. As Rasmus demonstrated, flipping that switch on for built-in functions results in a lot of work to 'clean' the code up, but you end up with having code that's not necessarily any better. Complely agree with that statement. I tried to explain the same thing multiple times already ... unfortunately with no success. That said, it's quite possible that the situation will be much improved if when we implement the less-strict rules we're proposing here, which would accept 32 as an integer or 37 as a float. That might work, if we're indeed looking for a compromise. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. And that brings us back to square one ... Expose only 1 tool to userland, but then give two options to the much less-populated crowd of extension developers. That doesn't make sense to me. So, from all these arguments, I now think that strict types, as defined in 0.3, are not the best solution. With option
RE: [PHP-DEV] Reviving scalar type hints
De : Lester Caine [mailto:les...@lsces.co.uk] Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? You didn't read it right. I was talking of conversions *from* bool, not *to* bool. (int - bool) is fine and will be preserved, but I propose to remove (bool - int). You will still return numbers as bool, and non-zero will still be converted to true. Relax :) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Zeev et al, 2. It is not not about being lossless or not. People expect bool - int to be disabled, for example, and it is not lossless. 3. It is more a question of finding a consensus about conversions which don't make sense, and disabling them. Examples include bool conversion to any other type and, of course, disabling trailing chars in numeric strings. I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Disagree. For a weak-mode, that does solve the problems that many people want solved. But it also ignores a lot of the problems that the strict crowd want solved. Let me show by example: function convertToInt(string $number): int { if (!preg_match((^[0-9]{1,17}$), $number)) { throw new InvalidArgumentException(Supplied argument is not a valid number); } return $number; } From a weak standpoint that looks like it should work. And from a pragmatic standpoint it should work as well. But from a static analysis standpoint, we can't tell. A static analyzer (one of the reasons people want strict) would error there. The reason is that *at compile time* it can't reason about the code well enough to determine if there's an error or not. You're passing a string where you expect an int. Is that going to work? We don't know. So the analyzer would need to throw a warning that the cast is potentially unsafe because it can't guarantee that the runtime won't throw an error. Which means that to remove the warning you'd need to add an explicit cast. At which point what does the weak mode buy us? Instead, if we make the strict mode behave based on types alone, this wouldn't be a problem (because we can detect ahead of time to 100% accuracy type errors in the strict mode files). And hence prevent errors at build time, rather than detecting them at runtime in prod. associated, built collectively over the last two decades. As Rasmus demonstrated, flipping that switch on for built-in functions results in a lot of work to 'clean' the code up, but you end up with having code that's not necessarily any better. That said, it's quite possible that the situation will be much improved if when we implement the less-strict rules we're proposing here, which would accept 32 as an integer or 37 as a float. And Every option has pros and cons. Since it's clear beyond a reasonable doubt that we can't all agree on purely weak type hints and equally on purely strict type hints, it becomes a question of what is the right compromise. Adding both - which at least from my point of view has major drawbacks (too prominent zval.type exposure; complexity of two systems; internal functions issue). Creating something in between that would handle most if not all of the use cases the strict camp brought up, while not (IMHO) overly focusing on zval.type and making things a lot more noisy/complex for built-in functions - is a better direction, whose advantage - I think - outweigh its disadvantages. Again, that changes the type checks from type checks to value checks. Which is fine for a weak mode (default mode of operation), but really throws away a large part of what many strict proponents want/need. And they won't be able to be satisfied unless zval.type is exposed fully. Because that's the point of strict typing and static analysis (and hence any compromise away from it reduces the value of the type hint to nothing). What you call issues, I call strengths. The internal functions issue is not really an issue at all to me because that's the entire point of type safety. And the fact that internal functions are already built-in with it is a bonus, not a drawback. The right compromise is the system that Andrea built. Because it **wasn't** a compromise (neither side had to give up anything). It gave both sides exactly what they want and need while letting them work together transparently. That doesn't sound like a compromise to me. That sounds like an innovative and ingenious design. And the fact that it hovered around 2/3 support the entire time shows that. Not to mention that several people (Daniel and Levi specifically, but others as well) *only* voted against it because of the declare semantics. There are a few details that should be worked out: 1. The switch syntax, as Sara straw-polled for (my vote is declare(strict_types=true) at the top of the file only) 2. The behavior of numeric types. Now, it's been said before here on this list that No other language is this strict about types. And that's patently false. I've done some research across major typed languages: VB, C and C++: Allows almost freeform movement between numeric types: http://en.cppreference.com/w/cpp/language/implicit_cast Java, D, C# and Pascal follow widening primitive style rules: http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 It allows only a widening primitive conversion. That means that you can call a function wanting a float and
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: François Laupretre [mailto:franc...@php.net] Sent: Tuesday, February 17, 2015 2:58 PM To: 'Sara Golemon'; 'Zeev Suraski' Cc: 'PHP internals' Subject: RE: [PHP-DEV] Reviving scalar type hints 2. It is not not about being lossless or not. People expect bool - int to be disabled, for example, and it is not lossless. 3. It is more a question of finding a consensus about conversions which don't make sense, and disabling them. Examples include bool conversion to any other type and, of course, disabling trailing chars in numeric strings. I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. 4. Once this is done, 99% of strict type proponents already said they would be OK with the so-called (not so) weak mode, making it possible to get rid of this far from perfect two-mode mechanism (actually, this two-mode approach more and more reminds me a great idea about bringing transparent Unicode support in PHP). Even though that's not what I meant when I sent my proposal in the morning, I've been wondering about the same thing (also with the feedback from Dmitry). Can go an extra step from both directions, and come up with a rule set that is stricter than the currently proposed weak hinting, but not as strict as the currently proposed strict hinting? Key challenge I see with that is that scalar type hinting would go farther apart from our implicit casting rules. However, the current RFC already aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting Apple as an int). Choosing between that and having two separate modes, I think that's the better option. * Exclude internal functions from the strict switch. (Perhaps have a separate switch for internal functions at a later date) This would make the feature inconsistent from an end user's pov. If a user enables strict mode, he assumes strict checks for every function he calls. *We* know that userspace and internal functions use different mechanisms, but the end user doesn't have to know. From his pov, a function is a function. I think that practically speaking, that is incorrect, at least from my experience with PHP developers. They do differentiate between built-in functions and userland functions. There are some fundamental differences between the two (being able to find their code, step into them in a debugger, find docs on php.net, etc.). As I mentioned earlier, the fundamental difference between built-in functions and userland functions in the context of our discussion is that if we introduce userland type hints, nothing happens before people change their code, and make (hopefully) informed decisions about what type hints to add, if any. No such luck with built-in functions, which have type information associated, built collectively over the last two decades. As Rasmus demonstrated, flipping that switch on for built-in functions results in a lot of work to 'clean' the code up, but you end up with having code that's not necessarily any better. That said, it's quite possible that the situation will be much improved if when we implement the less-strict rules we're proposing here, which would accept 32 as an integer or 37 as a float. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. So, from all these arguments, I now think that strict types, as defined in 0.3, are not the best solution. With option to introduce features such as the following at a later date: * Union types (e.g. function foo((int | float) $value): (bool | string) { ... }) * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as standard (like numeric), others user-definable) As I told Zeev, union types can be kept for the future if we don't go the nullable road, as it would be too confusing making 'string|null' and '?string' synonyms. I think we all agree about that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 7:02 AM, Dennis Birkholz den...@birkholz.biz wrote: Am 17.02.2015 um 12:30 schrieb Leigh: And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? As the library author you will never ever notice if your library was called in strict mode or not! And that is the point: you will not get any gain from making all your parameters strict, you will just force the user to cast (as Rasmus said already). No, and Rasmus examples, while being technically correct for some of them, just add confusions to the stack. The caller, and the calls to internals function in the caller codes, won't be affected, at all. Please understand it. Only the library code will. Now we can surely find other cases where we may adapt the patch or be more obvious, but for my own sake, get over this it will break and change everything everywhere, it does not. Repeating that strict mode is required from a library author's point of view does not make it right. You always get the types you want, you just limit the library consumer. No, you do not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Andrey Andreev [mailto:n...@devilix.net] Sent: Tuesday, February 17, 2015 4:49 PM To: Zeev Suraski Cc: franc...@php.net; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints Hi, On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z...@zend.com wrote: I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Agreed as well. However, while bool - int conversion one of the reasons why many people want strict type-hints, it also often makes sense and is quite widespread. There's no silver bullet for that problem. I'm not sure we need a silver bullet. If the conversion and acceptance rules are clear and reasonable, it's an entirely valid outcome that in cases where both int and bool are equally acceptable, you won't use a type hint but rather explicitly cast to int inside the function. But is it the best solution? The dual-mode approach was suggested because there is need and demand for *two* kinds of type-hinting. Most of the controversy and criticism came from the fact that introduces a switchable mode, while most of the praise received was due to somebody finally proposing *both* solutions at the same time. Every option has pros and cons. Since it's clear beyond a reasonable doubt that we can't all agree on purely weak type hints and equally on purely strict type hints, it becomes a question of what is the right compromise. Adding both - which at least from my point of view has major drawbacks (too prominent zval.type exposure; complexity of two systems; internal functions issue). Creating something in between that would handle most if not all of the use cases the strict camp brought up, while not (IMHO) overly focusing on zval.type and making things a lot more noisy/complex for built-in functions - is a better direction, whose advantage - I think - outweigh its disadvantages. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. And that brings us back to square one ... Expose only 1 tool to userland, but then give two options to the much less-populated crowd of extension developers. That doesn't make sense to me. First, let us hope that the situation will be much better to a level that we don't need to go in that direction :) But that said, I don't quite see it in the same way. Internal functions already commonly use a lot more advanced type checking than is commonly found in userland functions. Functions that behave differently depending on the type of argument you pass, on the number of arguments, etc. While technically it's possible to achieve in userland, it's a lot less common. So while I do see an issue here, I don't think it's *that* bad if it has to come to that. Unless we find out our rules work nicely out of the box for internal functions (which I'm still somewhat hopeful for) - there's no way to reconcile the fact that internal functions come with this long history of having detailed type data, while userland functions do not... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Lester Caine [mailto:les...@lsces.co.uk] My current practice up until now has been to use 'return false' when an action failed, but the main return would be a number of records or string of data. So you are now blocking that activity ... I'm reading to right, but you are not thinking all possibilities through. But I think I'm starting to see it broken already with the other changes to the core :( I'm not returning 'IS_FALSE' so I'm probably going to have to change the 'false' to '0' anyway so as to avoid the bool? Hi Lester, I am not blocking anything. My objective is to provide union types. Using union types, you will declare your return type as 'int|bool'. That's why I was pushing to integrate this feature in the first release. It will be done if we have enough time, but it is a lot to integrate in a discussion that must be quite short, as time is restricted. I am surely not thinking all possibilities :) but returning integer or false is usual and in scope. The solution is not to authorize (bool - int) conversion (as it would have to support (bool - anything)), but support 'int|bool', 'resource|bool', and similar syntax. So, the solution is completely different from the (int - bool) question. Even, if we don't release union types in 7.0, it will be clearly stated that it is a required follow-up. That's not perfect but we do it as fast as we can and everyone is welcome to help. What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : François Laupretre [mailto:franc...@php.net] This way, the user can write : function convertToInt(string $number): int! { - int! instead of int if (!preg_match((^[0-9]{1,17}$), $number)) { throw new InvalidArgumentException(Supplied argument is not a valid number); } return $number; A static analyzer would raise an error on this, as we are sure it fails, while : function convertToInt(string $number): int! { if (!preg_match((^[0-9]{1,17}$), $number)) { throw new InvalidArgumentException(Supplied argument is not a valid number); } return (int)$number; would be analyzed as OK. That's what you want, don't you ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Yes, I already know that. The difference, and why I keep pointing that out, is that me and many others want strict typing for our own reasons (but still in its entirety instead of as a limited mode) and most of us don't even care if you getting weak typing for your own usage. You can't work towards consensus if your target is to prevent the opposing group of getting what they want. I see both as valuable tools for different jobs and I want to have more tools at my disposal, while you're trying to tell me that I should use only one tool for everything. First, it's very important to understand that my target is to prevent the opposing group from getting what they want. I'm really not sadistic :) My reasons were obviously different and worked towards a different goal. Much in the same way that people who vote against an RFC - one of the countless that were voted against - don't do that to hurt the ones who support it. They do it because they think adding it would bring negative consequences. I never believed the 'You don't have to use it' as a silver bullet explanation for why it's OK to add features with potentially negative implications. The good news is that I think that in many ways the ideas we're toying with right now are better for the strict-type camp, especially if we end up going for just one mode, and meet roughly mid-way in terms of strict and weak - which I think is doable. The biggest gripes strict campers had with weak mode are gone in this proposal, and unlike v0.3 - that would actually be the default (and only) behavior, which is a big gain for the strict campers. And the most prominent features of weak typing are kept (dynamic type conversion where it makes sense), hopefully making the weak campers happy too. But you implied that most objections were from people who don't want strict typing in PHP at all. And I disagree with that because it's a speculation, which in turn you are using to favor your weak-hints-only case (hence, twisting it in another direction). I didn't imply it now (at least I certainly didn't intend to). I did outright say it a week or two ago, and still believe that's the case but reached the conclusion that none of us would gain anything from further discussing it. We won't know unless we start actually polling the people who voted and ask, which we're not going to do, and we're obviously not going to convince each other. Much more importantly, it at least *seems* as if we have a direction for something that a very wide audience may rally behind. Let's focus on that! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
I like 2) No possible confusion, and it's a clear tag. I agree, but it feels like it gets away from PHP's underscore-heavy syntax. The poll omitted ?php_strict -- that feels most PHP to me. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. Hopefully, though I think that we could embrace the idea of trailing space as insignificant. I'll propose *leading* and *trailing* whitespaces :) This doesn't cost much and can prove useful. 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type numeric string. 'numeric' can be implemented in two ways : a union type, or a new zpp type. I think I prefer the flexibility of union types. Maybe we'll have to include it in the first release, finally :) 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP to implement a stricter curl_setopt(), for example. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... I prefer defining four new 'strict' ZPP types for int, float, bool, and string (others are already strict). This way, the function decides what it accepts, not the user. Anyway, if we implement union types as strict-only, we will need these types. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Hi, Starting making the strict mode weaker is nonsense. It is not just Rasmus' example. Which exception do you authorize then ? Would you define a third 'pseudo-strict' mode ? And about static analyzers, will they be 'pseudo-strict' too ? No, if you want strict, it can only remain purely strict. I can understand the 'strict' position, but not the desire to make it weaker. Do you understand that, starting from the purely-strict position, I can give you use cases which will cause you to define additional exceptions, until you get the same conversion rules as I am currently defining ! The only difference is that I don't claim it being 'strict'. And 'numeric' is either a new ZPP type, or an alias for a future union type. Nothing to do with pure strict mode. These are all hacks trying to solve specific use cases. Regards François -Message d'origine- De : Jordi Boggiano [mailto:j.boggi...@seld.be] Envoyé : mardi 17 février 2015 17:26 À : internals@lists.php.net Objet : Re: [PHP-DEV] Reviving scalar type hints On 17/02/2015 15:47, Anthony Ferrara wrote: If we want to add a numeric type as a virtual union of int and float, that's one way to solve the concern. If we don't, we could also allow widening primitive conversion (int - float). That wouldn't work well with bigints, but would be fine in other cases. But there are plenty of languages that always require explicit type conversion. So even if we choose that, we're in good company. As far as I understand, allowing int - float would help fix a few of Rasmus' (or was it Benjamin?) concerns about things like sin() requiring floats in strict mode. It would make strict mode a lot more usable with C code as well. +1 on keeping the strictness benefits and remove some of the drawbacks. Having numeric in addition might be nice mostly for return values I guess, but it seems a bit redundant to me if int - float is allowed. As for the straw poll, I also think declare() is the clearest syntax, especially if it's enforced to appear at most once and on top of the file to remove any potential misuses. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon poll...@php.net a écrit: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. If nobody else does it, I will. I think Andrea's 0.3 proposal was extremely well balanced, served everyone's needs whether they would admit it or not, and who's only failing (subjectively termed) was the use of declare(). I think declare() is fine and not nearly as ugly as some have slandered it to be, but I'm willing to read the winds and modify it for v0.4. Straw poll: 1) ?php strict; 2) ?php-strict 3) use strict; (psuedo-namespace) 3) ?php // strict (I don't actually like HHVM's style, but if you do...) 4) declare(strict=true); (As a top-level declare only) 5) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) 6) your write-in vote here I'm not going to scope in union types, nullables, or falsables. We can leave that for a followup RFC, this one is contentious enough as it is. -Sara I like 2) No possible confusion, and it's a clear tag. But implementing 3) would be a good thing, since it is Hack syntax. Even if I don't like to use comments to enable something. If we have 2 similar features between PHP and Hack, I think it should have the same syntax, so there are minimum BC from one language to another, and people would spend less time to remember which syntax is the right syntax for PHP or Hack. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote: We can sigh and tut about this not being the PHP way, but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who should have that authority over their own application. I find this view way too extreme. You find giving authority over an application to the application author too extreme? And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? I'm sure I could find a way of detecting non-strict mode and throw a fatal, or force access through a facade/wrapper of some sort where I've turned on strict and made myself the caller. Isn't this equally unhelpful? The point is some people will want strict turned on, and they will find ways to force it on people. You're going to have to live with it, so just make it a possibility from the outset. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 18:33, François Laupretre wrote: What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I either already have clean defined data from the database, or I need to validate the data from users before using it. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Lester Caine [mailto:les...@lsces.co.uk] On 17/02/15 18:33, François Laupretre wrote: What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I If you can't see it after so much was written on the subject, what can we do ? Do you imply that, if *you* cannot understand the need, it does not exist ? either already have clean defined data from the database, or I need to validate the data from users before using it. If that's your only data source, that's OK. I confirm you probably don't need type hinting. You probably even don't need functions, classes and the rest. A 50-line script should fit. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. The point of type hinting is not validating user input. Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. That's different. There is overlapping there but the purpose is not the same. IDEs only can do a limited set of static analysis. As soon as you have indirect calls, IDE-based static analysis is down, let alone comment-stripped libraries and others. If you want more constraints on input and output, look at DbC (design by contract), as it can handle tests too slow to run in production. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. IDEs are worthwile but not mandatory and runtime features have nothing to do with IDEs. Now, you were (aggressively) complaining about returning int or false. You were sure you had found the case that would prove all of this was ready for the bin. I took the time to explain. Then, you're complaining it's no use because you don't understand its purpose and because you chose to bundle your arguments in arrays... Unfortunately, I'm afraid I can't do more for you but what I generally hate : 'If we don't like it, don't use it'. I try to be kind with constructive posts but, here, I have better to do. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/16/2015 09:48 PM, Sara Golemon wrote: Second, I should clarify that while the HHVM runtime performs coersion, the hack type checker is strict. So my original statement was inaccurate. As far as hack is concerned, it's simply strict. Period. With both the default (partial) type checking and strict enabled, my number_format() example in Hack produces: int(1000) 1,000 string(4) 1000 1,000 float(1000) 1,000 string(5) 1000 Warning: number_format() expects parameter 1 to be double, string given string(5) 1000 1,000 string(9) 1000 dogs Warning: number_format() expects parameter 1 to be double, string given string(3) dog Warning: number_format() expects parameter 1 to be double, string given resource(4) of type (stream) Warning: number_format() expects parameter 1 to be double, resource given Basically it accepts, ints, floats and well-formed numeric strings and the hh_client type checker is telling me I have No errors. So the only difference between Hack's strict mode and the current coercive behaviour in PHP is strings with trailing chars. The 1000 dogs case. 1000 as well in my example, but that is the same case. Where in PHP you get a notice but it still does the conversion and in Hack you get a warning and the conversion isn't done. So even though Hack has both a partial type checking mode and a strict mode, the decision was to still do type coercion for the others. I kind of expected it to only accept a float in full-on strict mode to mimic the no-compromise strictness proposed in the RFC. Also, looking through the code, I really don't see this simply strict anywhere when it comes to calling internal functions. For example: $a = [1,2,3,4,5]; print_r(array_reverse($a,0)); It doesn't complain that 0 is a string and not a boolean. It doesn't even complain about dog there. And the one everyone gets uppity about. bool-int conversion in curl_setopt(). eg. $ch = curl_init(https://74.125.28.104;); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); echo curl_exec($ch); echo curl_error($ch); PHP obviously converts true to 1 there which has been a problem because what people really meant was to set it to 2. We spew a notice for this, of course: Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST with value 1 is deprecated and will be removed as of libcurl 7.28.1. It is recommended to use value 2 instead in ... In Hack it appears that true is also converted to 1 in ?hh // strict mode and no notice appears and the hh_client type checker doesn't complain. If instead of true I pass in an array of strings, it still converts it to 1 even though the type is blatantly wrong. It looks like it was kept quite loose to match PHP and not cause too much legacy code to break. In this particular case it is pretty dangerous to be completely silent about it though since it actually means no host verification is getting done. The output when properly set to 2 from both PHP and Hack is: SSL: certificate subject name 'www.google.com' does not match target host name '74.125.28.104' Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. eg. ?hh // strict function test() : int { $ch = curl_init(https://74.125.28.104;); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, [I have no idea what I am doing]); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); echo curl_exec($ch); echo curl_error($ch); return beer; } hh_client reports: /home/rasmus/test/a.php:8:12,17: Invalid return type (Typing[4110]) /home/rasmus/test/a.php:2:19,21: This is an int /home/rasmus/test/a.php:8:12,17: It is incompatible with a string When I change return beer to return 1 hh_client is happy. So, you keep asking what I would support. I would like to see an RFC along the following lines: 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. 2a. In strict mode, tone down the strictness and allow non-lossy coercion including int-float. And yes, I know in really edge cases that isn't technically non-lossy, but for all practical purposes it is. or 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 21:28, François Laupretre wrote: De : Lester Caine [mailto:les...@lsces.co.uk] On 17/02/15 18:33, François Laupretre wrote: What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I If you can't see it after so much was written on the subject, what can we do ? Do you imply that, if *you* cannot understand the need, it does not exist ? Since it has already been said that what is proposed is 'just a start' then the missing bits may get added later - and if it is anything like PDO will it arrive before PHP10 :) either already have clean defined data from the database, or I need to validate the data from users before using it. If that's your only data source, that's OK. I confirm you probably don't need type hinting. You probably even don't need functions, classes and the rest. A 50-line script should fit. http://hg.lsces.org.uk/bw/bitweaver/ is a little more than 50 lines ... lsces.org.uk/bitweaverdocsPHP/index.html hasn't been updated since we lost the original phpDocumentor but now I do need to try and get a new version run including all the e_strict stuff that hs been reworked in the last 5 years. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. The point of type hinting is not validating user input. Again limited application of a useful function. Strict scalar type hints are only there to give an error when something is wrong. How is that not doing validation? If you HAVE validated the data then where do you need the hint other than reminding you just what you need to validate to? And if you have validated then one can pass a value rather than a string anyway? Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. That's different. There is overlapping there but the purpose is not the same. IDEs only can do a limited set of static analysis. As soon as you have indirect calls, IDE-based static analysis is down, let alone comment-stripped libraries and others. If you want more constraints on input and output, look at DbC (design by contract), as it can handle tests too slow to run in production. I would not even bother trying to understand the PHP code base without a decent IDE, and Eclipse provides that. PHP files live next to C/C++ and other file formats, so the one set of tools allow everything to work productively. I don't find any problem seeing indirect call annotation and although PHPeclipse is now struggling with new things ( like dropping the ? in the MIDDLE of phpt files :( ) it has done the jobs that most of this extra infrastructure is trying to duplicate for a lot of the life of PHP5. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. IDEs are worthwile but not mandatory and runtime features have nothing to do with IDEs. Now, you were (aggressively) complaining about returning int or false. You were sure you had found the case that would prove all of this was ready for the bin. I took the time to explain. Then, you're complaining it's no use because you don't understand its purpose and because you chose to bundle your arguments in arrays... Flagging that a value HAS to be an integer is fine, and hopefully the move to make that an unconstrained object rather than a simple register value has passed, but even here the next step is rather than hiding the fact that in many cases there IS a limit, the move to 64bit values in parallel with 32bit ones needs much better management and it's the total disregard for that which is my problem. 'PHP has not worried about that in the past' neatly sidesteps the fact that we USED 32bit builds of PHP5 to avoid the problems, but nowadays we have legacy systems that are still locked to 32bit values while new systems are running 64bit and so now it IS something to at least take some interest in. int4 and int8 are equally as important as int(unlimited) and while ignoring 32bit builds may be practical for some, it still has a place in many areas. Unfortunately, I'm afraid I can't do more for you but what I generally hate : 'If we don't like it, don't use it'. I try to be kind with constructive posts but, here, I have better to do.
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 9:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/16/2015 09:48 PM, Sara Golemon wrote: Second, I should clarify that while the HHVM runtime performs coersion, the hack type checker is strict. So my original statement was inaccurate. As far as hack is concerned, it's simply strict. Period. With both the default (partial) type checking and strict enabled, my number_format() example in Hack produces: int(1000) 1,000 string(4) 1000 1,000 float(1000) 1,000 string(5) 1000 Warning: number_format() expects parameter 1 to be double, string given string(5) 1000 1,000 string(9) 1000 dogs Warning: number_format() expects parameter 1 to be double, string given string(3) dog Warning: number_format() expects parameter 1 to be double, string given resource(4) of type (stream) Warning: number_format() expects parameter 1 to be double, resource given Basically it accepts, ints, floats and well-formed numeric strings and the hh_client type checker is telling me I have No errors. So the only difference between Hack's strict mode and the current coercive behaviour in PHP is strings with trailing chars. The 1000 dogs case. 1000 as well in my example, but that is the same case. Where in PHP you get a notice but it still does the conversion and in Hack you get a warning and the conversion isn't done. So even though Hack has both a partial type checking mode and a strict mode, the decision was to still do type coercion for the others. I kind of expected it to only accept a float in full-on strict mode to mimic the no-compromise strictness proposed in the RFC. Also, looking through the code, I really don't see this simply strict anywhere when it comes to calling internal functions. For example: $a = [1,2,3,4,5]; print_r(array_reverse($a,0)); It doesn't complain that 0 is a string and not a boolean. It doesn't even complain about dog there. And the one everyone gets uppity about. bool-int conversion in curl_setopt(). eg. $ch = curl_init(https://74.125.28.104;); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); echo curl_exec($ch); echo curl_error($ch); PHP obviously converts true to 1 there which has been a problem because what people really meant was to set it to 2. We spew a notice for this, of course: Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST with value 1 is deprecated and will be removed as of libcurl 7.28.1. It is recommended to use value 2 instead in ... I think curl_setopt is a misleading example in the typehinting discussion, because this kind of API does not benefit from it. The third argument depends on the second argument and requires a generic type in code: curl_setopt(resource $ch, int $option, mixed $data); It won't be possible to change this (or any similar API) with strict type hints. The code to convert a boolean $data to integer in the VERIFYPEER case is manually implemented and therefore subject to the implementors design decisions. In Hack it appears that true is also converted to 1 in ?hh // strict mode and no notice appears and the hh_client type checker doesn't complain. If instead of true I pass in an array of strings, it still converts it to 1 even though the type is blatantly wrong. It looks like it was kept quite loose to match PHP and not cause too much legacy code to break. In this particular case it is pretty dangerous to be completely silent about it though since it actually means no host verification is getting done. The output when properly set to 2 from both PHP and Hack is: SSL: certificate subject name 'www.google.com' does not match target host name '74.125.28.104' Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. eg. ?hh // strict function test() : int { $ch = curl_init(https://74.125.28.104;); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, [I have no idea what I am doing]); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); echo curl_exec($ch); echo curl_error($ch); return beer; } hh_client reports: /home/rasmus/test/a.php:8:12,17: Invalid return type (Typing[4110]) /home/rasmus/test/a.php:2:19,21: This is an int /home/rasmus/test/a.php:8:12,17: It is incompatible with a string When I change return beer to return 1 hh_client is happy. So, you keep asking what I would support. I would like to see an RFC along the following lines: 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. 2a. In strict mode, tone down the
Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:11 AM, Benjamin Eberlei wrote: I think curl_setopt is a misleading example in the typehinting discussion, because this kind of API does not benefit from it. The third argument depends on the second argument and requires a generic type in code: curl_setopt(resource $ch, int $option, mixed $data); It won't be possible to change this (or any similar API) with strict type hints. The code to convert a boolean $data to integer in the VERIFYPEER case is manually implemented and therefore subject to the implementors design decisions. Sure, I realize this, but it is the bool-int coercion example that is always brought up. A static analysis type checker would have trouble catching this, but both PHP and Hack apply that coercion at runtime: case CURLOPT_SSL_VERIFYHOST: if(Z_BVAL_PP(zvalue) == 1) { The runtime could say, hey, I am in strict mode here and you are passing me an array of strings which I am coercing to a boolean. Not cool. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Reviving scalar type hints
2015-02-17 0:58 GMT+01:00 Sara Golemon poll...@php.net: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Straw poll: 1) ?php strict; 2) ?php-strict 3) use strict; (psuedo-namespace) 4) ?php // strict (I don't actually like HHVM's style, but if you do...) 5) declare(strict=true); (As a top-level declare only) 6) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) 7) your write-in vote here (i changed double 3 voting option in quote) +1 for all which can only be defined on the first line so: 1,2, 4, 5
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 06:20, Sara Golemon wrote: * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as standard (like numeric), others user-definable) And also ... int4, int8 and similar for correctly constrained values. In an ideal world the whole SQL standard types would be available, but this at least would allow int to become an unconstrained object if people want that. It's the whole we can fix it later that I don't like ... especially when other votes are changing the goal posts in parallel. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Mon, 16 Feb 2015, Sara Golemon wrote: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. If nobody else does it, I will. Please do! I think Andrea's 0.3 proposal was extremely well balanced, served everyone's needs whether they would admit it or not, and who's only failing (subjectively termed) was the use of declare(). I think declare() is fine and not nearly as ugly as some have slandered it to be, but I'm willing to read the winds and modify it for v0.4. Straw poll: These two are my preference: 3) use strict; (psuedo-namespace) 4) declare(strict=true); (As a top-level declare only) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Hi Sara, De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon So, if you'll permit me to summarize your message. The following would be palatable to you? * Lossless coercion. This would sit somewhere between strict types and weak types as lossy conversions (object-__toString() for objects passed where string expected, any-bool) would be disallowed, but lossless conversions (numeric strings to number types, int to float, whole floats to ints, numbers to strings -- But no implicit conversions to bools, no non-numeric strings to numerics, etc...) 1. it must be implemented as a modification to zpp conversion rules. IMHO, a third mode would be the worst thing to do. 2. It is not not about being lossless or not. People expect bool - int to be disabled, for example, and it is not lossless. 3. It is more a question of finding a consensus about conversions which don't make sense, and disabling them. Examples include bool conversion to any other type and, of course, disabling trailing chars in numeric strings. 4. Once this is done, 99% of strict type proponents already said they would be OK with the so-called (not so) weak mode, making it possible to get rid of this far from perfect two-mode mechanism (actually, this two-mode approach more and more reminds me a great idea about bringing transparent Unicode support in PHP). If future development tools require more precise types (and they probably will), the mechanism can be extended with new keywords, but the idea is never using the same keyword for different ways to check a zval. New keywords would be defined at the zpp level, keeping internal and userspace features in sync. Would you agree proposing this as an option in 0.4 ? Actually, I will write it as a separate RFC as modifying zpp conversion rules has impacts well beyond type hinting. Then, type hinting RFCs can reference it. * Exclude internal functions from the strict switch. (Perhaps have a separate switch for internal functions at a later date) This would make the feature inconsistent from an end user's pov. If a user enables strict mode, he assumes strict checks for every function he calls. *We* know that userspace and internal functions use different mechanisms, but the end user doesn't have to know. From his pov, a function is a function. If the documentation states that the function he's calling in strict mode accepts int, he will expect int to be checked in strict mode. We cannot say 'Oh, wait, it's an internal function, the rules are not the same'. The distinction between internal and userpace functions is irrelevant for him and has to remain so. So, from all these arguments, I now think that strict types, as defined in 0.3, are not the best solution. With option to introduce features such as the following at a later date: * Union types (e.g. function foo((int | float) $value): (bool | string) { ... }) * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as standard (like numeric), others user-definable) As I told Zeev, union types can be kept for the future if we don't go the nullable road, as it would be too confusing making 'string|null' and '?string' synonyms. The question of null is not so simple. IMO, it should be left for a future discussion about union types. Anyway, once people get used to scalar hinting, the need for union types will arise quickly. Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 16 February 2015 at 16:42, François Laupretre franc...@php.net wrote: Hi, De : Arvids Godjuks [mailto:arvids.godj...@gmail.com] The 0.1 RFC version was mentioned a lot as a good compromise by many people and had major support. Maybe someone competent could pick it up, make necessary adjustments that where required and let people vote on it? Start with small steps - get the weak type hints into the language first, see how it gets used and then we can always add strict type hints if there is a need/desire to do that. That way we finally get type hints into the language, and those wanting the strict variety have all the opportunities in the world to add them at a later release with proper discussion and development time. That's what I am planning. If I write an RFC, it will be based on Andrea's 0.1/0.2 version, and won't propose different modes. The problem is that the previous controversial RFC focused people on weak vs strict typing, while we should have explored other technical concerns. Here are the main ones I see : - the fact that the RFC supports single types only, like the previous 'return type' RFC. While it is easier to implement, it opens several issues as multiply-typed arguments are an integral part of the PHP language (mostly completeness and compatibility with internal function hinting). If we want to support multiple types the same way for internal and userspace functions, we must extend the ZPP layer to support it. - the mechanism to check for type hints on internal functions, while easy to implement, is not sufficient, as a lot of internal functions get a bare zval from the parsing system and then convert it by themselves. With the proposed mechanism, there's no possible hinting on such argument, which will make the implementation different from the documentation. Even if the check is done by the function body, it won't be done in a consistent way with type hinting checks and won't raise a similar error. As most cases are related to multiply-typed args, the solution is in adding multiply-typed support to ZPP. Multiply-typed support needs to redefine scalar conversion rules, to take care of the target type being a combination of single types. - We need to define the appropriate extension to Reflection parameters/return type. That's not complex, but it takes time. - Other changes I'd like to propose are exposed in Bob Weinand's article, at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article explains how restricting weak conversion possibilities would make strict typing almost useless. Changes include forbidding bool to int/float or '7years' to int. This cannot be left for future additions as BC breaks will make it impossible. To remain consistent between userspace/internal functions, this must also be done at the ZPP level. - Using bare class names as type hints is a potential issue too, as it makes reserved keywords and class names share the same naming space. I think we should deprecate the use of class names as type hints in favor of 'object(class-name)'. If we don't do that, every future addition of a type hint keyword will cause a BC break (and will be practically impossible). - Additional 'hybrid' types like 'numeric' and 'mixed' should be also provided. So, most features I have in mind are really 'now or never'. My main concern, anyway, is with March 15 announced feature freeze. If we need a vote by this date, it's impossible. And planning such BC for 7.1 is probably unrealistic because of the huge syntax additions and BC breaks it brings. So, if it's too late for an inclusion in 7.0, I think I'll give up. So, could someone confirm what 'feature freeze' exactly means ? Note that the accepted timeline for PHP 7 [1] states that we will have three months to Finalize implementation testing of new features, after the March deadline. That should give us some time to tie down the actual implementation side of things. Apart from that, it's more a matter of getting an RFC drafted, discussed, voted on, before the March deadline. I, for one, wouldn't mind the vote taking a wee while longer (say, a week or two) if it means we can get this feature added. Regards François The main issues are completeness (we can give hints for some cases, but not for others) and, more important, the compatibility with internal functions. As Andrea herself agreed, her mechanism for type hinting on internal functions is not sufficient. Just using the ZPP macros, as they exist today, won't work as a lot of internal functions get a bare zval and then convert it by themselves. So, in this case, we would check nothing. So, an argument described as 'string|array' in the documentation, wouldn't produce the same sort of error when sent an object, than its friend, described as 'string'. This is not consistent and will open a lot of side effects if it is left out of the type hint layer. --
Re: [PHP-DEV] Reviving scalar type hints
On Mon, Feb 16, 2015 at 7:42 PM, François Laupretre franc...@php.net wrote: Hi, De : Arvids Godjuks [mailto:arvids.godj...@gmail.com] The 0.1 RFC version was mentioned a lot as a good compromise by many people and had major support. Maybe someone competent could pick it up, make necessary adjustments that where required and let people vote on it? Start with small steps - get the weak type hints into the language first, see how it gets used and then we can always add strict type hints if there is a need/desire to do that. That way we finally get type hints into the language, and those wanting the strict variety have all the opportunities in the world to add them at a later release with proper discussion and development time. That's what I am planning. If I write an RFC, it will be based on Andrea's 0.1/0.2 version, and won't propose different modes. I would propose exactly Andrea's 0.1. Most people were agree to support weak type hints by default. This proposal won't prevent feature addition of optional strict type hints. All are tired from endless arguing. The problem is that the previous controversial RFC focused people on weak vs strict typing, while we should have explored other technical concerns. Here are the main ones I see : - the fact that the RFC supports single types only, like the previous 'return type' RFC. While it is easier to implement, it opens several issues as multiply-typed arguments are an integral part of the PHP language (mostly completeness and compatibility with internal function hinting). If we want to support multiple types the same way for internal and userspace functions, we must extend the ZPP layer to support it. this is not a big technical problem. - the mechanism to check for type hints on internal functions, while easy to implement, is not sufficient, as a lot of internal functions get a bare zval from the parsing system and then convert it by themselves. With the proposed mechanism, there's no possible hinting on such argument, which will make the implementation different from the documentation. Even if the check is done by the function body, it won't be done in a consistent way with type hinting checks and won't raise a similar error. As most cases are related to multiply-typed args, the solution is in adding multiply-typed support to ZPP. Multiply-typed support needs to redefine scalar conversion rules, to take care of the target type being a combination of single types. I wouldn't rise this question. Lets it work as is for now. - We need to define the appropriate extension to Reflection parameters/return type. That's not complex, but it takes time. It's a subject for separate more or less obvious RFC. - Other changes I'd like to propose are exposed in Bob Weinand's article, at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article explains how restricting weak conversion possibilities would make strict typing almost useless. Changes include forbidding bool to int/float or '7years' to int. This cannot be left for future additions as BC breaks will make it impossible. To remain consistent between userspace/internal functions, this must also be done at the ZPP level. Lets go forward by small steps. If we would do it before we would already got all the features. We may restrict ZPP rules by next RFC. I'll most probably support it. The same for the rest. Thanks. Dmitry. - Using bare class names as type hints is a potential issue too, as it makes reserved keywords and class names share the same naming space. I think we should deprecate the use of class names as type hints in favor of 'object(class-name)'. If we don't do that, every future addition of a type hint keyword will cause a BC break (and will be practically impossible). - Additional 'hybrid' types like 'numeric' and 'mixed' should be also provided. So, most features I have in mind are really 'now or never'. My main concern, anyway, is with March 15 announced feature freeze. If we need a vote by this date, it's impossible. And planning such BC for 7.1 is probably unrealistic because of the huge syntax additions and BC breaks it brings. So, if it's too late for an inclusion in 7.0, I think I'll give up. So, could someone confirm what 'feature freeze' exactly means ? Regards François The main issues are completeness (we can give hints for some cases, but not for others) and, more important, the compatibility with internal functions. As Andrea herself agreed, her mechanism for type hinting on internal functions is not sufficient. Just using the ZPP macros, as they exist today, won't work as a lot of internal functions get a bare zval and then convert it by themselves. So, in this case, we would check nothing. So, an argument described as 'string|array' in the documentation, wouldn't produce the same sort of error when sent an object, than its friend, described as 'string'. This is not
RE: [PHP-DEV] Reviving scalar type hints
Hi, De : morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] De la part Also, I know people REALLY want scalar types in PHP 7.0 but honestly all we need to do is reserve the keywords so there is no BC impact and then we can do it at any point during the PHP 7 lifecycle. This is my preferred course of action, because right now this internals mailing list is in HIGH STRESS MODE. I would rather just take the action of reserving the types so it can be done in 7.1 (or 7.2 or even if it's never, I would prefer to reserve these words). If we deprecate using bare class names as type hints and replace it with the 'object(classname)' syntax, we can reserve keywords for 7.0 and, maybe 7.1 but potential name clashes should be away in 7.2. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Mon, Feb 16, 2015 at 5:42 PM, François Laupretre franc...@php.net wrote: Hi, - the fact that the RFC supports single types only, like the previous 'return type' RFC. While it is easier to implement, it opens several issues as multiply-typed arguments are an integral part of the PHP language (mostly completeness and compatibility with internal function hinting). If we want to support multiple types the same way for internal and userspace functions, we must extend the ZPP layer to support it. - the mechanism to check for type hints on internal functions, while easy to implement, is not sufficient, as a lot of internal functions get a bare zval from the parsing system and then convert it by themselves. With the proposed mechanism, there's no possible hinting on such argument, which will make the implementation different from the documentation. Even if the check is done by the function body, it won't be done in a consistent way with type hinting checks and won't raise a similar error. As most cases are related to multiply-typed args, the solution is in adding multiply-typed support to ZPP. Multiply-typed support needs to redefine scalar conversion rules, to take care of the target type being a combination of single types. Hello, I know this is probably a pretty unpopular opinion in PHP (based on the replies I got in the other thread), but different values for parameters should be IMHO solved by method overloading and such. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Mon, Feb 16, 2015 at 9:42 AM, François Laupretre franc...@php.net wrote: Hi, De : Arvids Godjuks [mailto:arvids.godj...@gmail.com] The 0.1 RFC version was mentioned a lot as a good compromise by many people and had major support. Maybe someone competent could pick it up, make necessary adjustments that where required and let people vote on it? Start with small steps - get the weak type hints into the language first, see how it gets used and then we can always add strict type hints if there is a need/desire to do that. That way we finally get type hints into the language, and those wanting the strict variety have all the opportunities in the world to add them at a later release with proper discussion and development time. That's what I am planning. If I write an RFC, it will be based on Andrea's 0.1/0.2 version, and won't propose different modes. The problem is that the previous controversial RFC focused people on weak vs strict typing, while we should have explored other technical concerns. Here are the main ones I see : - the fact that the RFC supports single types only, like the previous 'return type' RFC. While it is easier to implement, it opens several issues as multiply-typed arguments are an integral part of the PHP language (mostly completeness and compatibility with internal function hinting). If we want to support multiple types the same way for internal and userspace functions, we must extend the ZPP layer to support it. - the mechanism to check for type hints on internal functions, while easy to implement, is not sufficient, as a lot of internal functions get a bare zval from the parsing system and then convert it by themselves. With the proposed mechanism, there's no possible hinting on such argument, which will make the implementation different from the documentation. Even if the check is done by the function body, it won't be done in a consistent way with type hinting checks and won't raise a similar error. As most cases are related to multiply-typed args, the solution is in adding multiply-typed support to ZPP. Multiply-typed support needs to redefine scalar conversion rules, to take care of the target type being a combination of single types. - We need to define the appropriate extension to Reflection parameters/return type. That's not complex, but it takes time. - Other changes I'd like to propose are exposed in Bob Weinand's article, at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article explains how restricting weak conversion possibilities would make strict typing almost useless. Changes include forbidding bool to int/float or '7years' to int. This cannot be left for future additions as BC breaks will make it impossible. To remain consistent between userspace/internal functions, this must also be done at the ZPP level. - Using bare class names as type hints is a potential issue too, as it makes reserved keywords and class names share the same naming space. I think we should deprecate the use of class names as type hints in favor of 'object(class-name)'. If we don't do that, every future addition of a type hint keyword will cause a BC break (and will be practically impossible). - Additional 'hybrid' types like 'numeric' and 'mixed' should be also provided. So, most features I have in mind are really 'now or never'. My main concern, anyway, is with March 15 announced feature freeze. If we need a vote by this date, it's impossible. And planning such BC for 7.1 is probably unrealistic because of the huge syntax additions and BC breaks it brings. So, if it's too late for an inclusion in 7.0, I think I'll give up. So, could someone confirm what 'feature freeze' exactly means ? Regards François The main issues are completeness (we can give hints for some cases, but not for others) and, more important, the compatibility with internal functions. As Andrea herself agreed, her mechanism for type hinting on internal functions is not sufficient. Just using the ZPP macros, as they exist today, won't work as a lot of internal functions get a bare zval and then convert it by themselves. So, in this case, we would check nothing. So, an argument described as 'string|array' in the documentation, wouldn't produce the same sort of error when sent an object, than its friend, described as 'string'. This is not consistent and will open a lot of side effects if it is left out of the type hint layer. I have a sum types RFC that isn't ready for discussion. However, since you have mentioned the functionality it here is the preliminary RFC: https://wiki.php.net/rfc/sum_types. Also, I know people REALLY want scalar types in PHP 7.0 but honestly all we need to do is reserve the keywords so there is no BC impact and then we can do it at any point during the PHP 7 lifecycle. This is my preferred course of action, because right now this internals mailing list is in
RE: [PHP-DEV] Reviving scalar type hints
Hi Dmitry De : Dmitry Stogov [mailto:dmi...@zend.com] I would propose exactly Andrea's 0.1. Most people were agree to support weak type hints by default. This proposal won't prevent feature addition of optional strict type hints. All are tired from endless arguing. Yes, but that's not exactly what I had in mind. I thought we could just use it as a base, and add features that, for any reason, will be much harder to implement in the future. However, most of the work I want to do deals with ZPP macros, which are not so complex. And userspace type hints follow ZPP rules, so ZPP changes will apply to internal and userspace functions automatically. The first thing to do is restricting authorized parsing conversions (ZPP *and* zend_parse_parameters must matc here) to get approval from strict-typing fans (tan(1) and curl use cases must be solved first). Then, define multi-type conversion rules and implement that in ZPP (just ZPP, not zend_parse_parameters). Once it is available in ZPP, internal functions will migrate from Z_PARAM_ZVAL at their own pace but the mechanism must exist before functions can gradually use it. I would really like to implement multi-type support now. IMO, it is one of the most useful characteristics I expect from type hinting. Multi-typed argument are natural in PHP from the beginning and should have been part of the RFC from its beginning too. If people start describing multi-type args as 'mixed', which is not the same information, they won't come back and do the work again with more precise types, asking whether each 'mixed' is a 'real' mixed or just a placeholder waiting for us to implement the rest. I am especially concerned with the fact that a good part of userspace function arguments will be just impossible to type, except as 'mixed', which is not accurate in most cases. 3 lines above the argument declaration, a phpdoc comment says that $arg is 'string|array', but the user cannot transmit the information to the engine... I know it may be a question of time but it saddens me. I propose you implement the parser/userspace part (I don't know what remains to be done) and I write and implement ZPP restrictions and multi-type support. I'll try to define ZPP restrictions (single type) tonight. I'll also read the 0.1 RFC again and send comments if I have some. I already know that I want to add the 'resource' type because Andrea's argument is fake, IMO (and it would make it the only type without a hint). - We need to define the appropriate extension to Reflection parameters/return type. That's not complex, but it takes time. It's a subject for separate more or less obvious RFC. Would feature freeze also apply to such work ? Before I write anything, what do you think of suppressing conversions to/from IS_NULL in zpp (provided we support multi-typed args, of course ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote: De : Pavel Kouril [mailto:pajou...@gmail.com] Hello, I know this is probably a pretty unpopular opinion in PHP (based on the replies I got in the other thread), but different values for parameters should be IMHO solved by method overloading and such. The question is not that it's unpopular, it's that 1. It requires strict types, and 2. If we want to solve this by polymorphism, we must also support polymorphism on functions. Now, tell me how you would solve the tan(int|float) case with polymorphism ? One 'tan' function for int, one for float ? str_replace(string|array, string|array, string|array, int ) is also a nice case to study if you can't sleep... Sorry but polymorphism on scalar types is possible with strict types only, which is out of scope for the next RFC. François I will get to this more tomorrow, but now just a short notes: I'd only have tan(float) with int being able to be passed and the value would be implicitly converted to float. This is something even strongly typed languages normally do, and there is no reason PHP shouldn't be able to. If somebody would make a tan(float) and tan(int) declarations, then when calling tan($x), the apropriate one based on current type of $x should be called. I don't see any reason why this can be done only for strongly typed languages; could you name exact reasons? The str_replace(string|array $search, string|array $replace, string|array $subject[, int $count ]) is a harder one to comment on though. I will refrain from answering on that one right now and will get back to that one tomorrow, because that one needs a little bit more thinking. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Philip Sturgeon [mailto:pjsturg...@gmail.com] I know it is very easy for people to say Well, that v0.3 that I didn't like has been withdrawn, so let's just crack on and do some other new thing. It's not so easy. It would be easier to do as you suggest. And you can still do it in your name. Andrea's had agreed we should write a follow-up RFC to solve open issues we had identified. This is what I am proposing here, nothing more. It is not some 'other new thing'. It's mostly a way to bring strict-typing fans back to consensus. Of course, you may find it useless... but I would have to ask people to consider that v0.3 had two thirds majority, with a few people clearly admitting that their No vote was down to declare. Even if we got 4 or 5 people change their mind because of a new declare syntax, it is clear that we don't have consensus on this topic. So, IMO, the RFC is dead, whatever 2/3 or 3/4 we may have. Once it was clear that both camps would never agree, with every PHP founders against it, pushing it was useless. We're not electing a president, we're trying to ensure we make the right decision. The spirit is not the same. So, if declare is the only thing blocking v0.3 from passing, despite 1/3rd of voters being sad about it, let's just go down that road instead of throwing the baby out with the bath water and coming up with some new approach that will be bike-shedded over until PHP 8 is in feature freeze. I am also writing this because I think the two-mode approach is by far not the best one, as it would probably generate a lot of side effects we don't even imagine now. I voted 'yes' because I thought that was nice to have it in PHP 7 instead of nothing but, now, the RFC is dead and I am free to propose what I have in mind, especially in the hope that it can bring a consensus where it is lacking. Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Pavel Kouril [mailto:pajou...@gmail.com] Hello, I know this is probably a pretty unpopular opinion in PHP (based on the replies I got in the other thread), but different values for parameters should be IMHO solved by method overloading and such. The question is not that it's unpopular, it's that 1. It requires strict types, and 2. If we want to solve this by polymorphism, we must also support polymorphism on functions. Now, tell me how you would solve the tan(int|float) case with polymorphism ? One 'tan' function for int, one for float ? str_replace(string|array, string|array, string|array, int ) is also a nice case to study if you can't sleep... Sorry but polymorphism on scalar types is possible with strict types only, which is out of scope for the next RFC. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 16 February 2015 at 22:00, Philip Sturgeon pjsturg...@gmail.com wrote: I know it is very easy for people to say Well, that v0.3 that I didn't like has been withdrawn, so let's just crack on and do some other new thing. but I would have to ask people to consider that v0.3 had two thirds majority, with a few people clearly admitting that their No vote was down to declare. So, if declare is the only thing blocking v0.3 from passing, despite 1/3rd of voters being sad about it, let's just go down that road instead of throwing the baby out with the bath water and coming up with some new approach that will be bike-shedded over until PHP 8 is in feature freeze. Hear, hear. -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara Golemon Sent: Tuesday, February 17, 2015 1:58 AM To: franc...@php.net Cc: Philip Sturgeon; Arvids Godjuks; Jefferson Gonzalez; Rowan Collins; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. If nobody else does it, I will. I think Andrea's 0.3 proposal was extremely well balanced, served everyone's needs whether they would admit it or not, and who's only failing (subjectively termed) was the use of declare(). I think declare() is fine and not nearly as ugly as some have slandered it to be, but I'm willing to read the winds and modify it for v0.4. Straw poll: 1) ?php strict; I like this one best. Obviously it requires some extra definition (e.g. I assume it will only be possible at the first block, perhaps only as the first part of the file or such). That syntax poll aside, I had what I hope is some sort an enlightenment, and I think I know what will get me to cast my vote in favor of 'strict', as a true supporter. There's one very special conversion that's too common in PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the cases, if not strictly 100%: string-int or string-float conversions, when the string looks *exactly* like a number. Given almost all of our inputs (from databases, forms, files, etc.) come in string form, that's by far the conversion that's going to give us the most trouble - and is most probably the use case that by far is going to result the largest amount of explicit casts to work around that problem. What if strict mode didn't just blindly check zval.type, but actually allowed for this one type of conversion to go through without a problem? No bool to int. No Apple to int. No 123 testing to float. Just 32 to 32 and 37.7 to 37.7. Can the strict supporting camp consider that option? Judging by the examples brought up by proponents of v0.3, this type of conversion isn't their issue. It's the 'obviously wrong' conversions that bug them. As a secondary concern I'd put int to float conversions where no (meaningful) data is being lost, e.g. 37 - 37.0, even though a tiny bit of accuracy is lost. Rejecting this particular conversion places us at being stricter than mostly all other languages. That said, it's a much less common conversion so I don't feel nearly as strongly about it as the string one. Last, regarding internal functions, I do agree with Rasmus and Drew. Again, judging by the examples brought up as a part of the discussion, it seems as if we gave ZPP developers a standard easy way of being a lot more picky about the types of values of particular arguments, and allowing them to do this selectively for those places that are very sensitive (e.g. curl_setopt()) would be a more suitable solution than just turning strict validation for all internal functions, which were built with very very different assumptions in mind. The biggest difference between internal functions and userland functions in the context of this RFC is that with userland functions, we're starting with a clean slate. There are no type hint definitions anywhere, developers can selectively add them as they see fit. With internal functions, we have type requirements EVERYWHERE already, but with semantics that didn't take strict typing into account at all and evolved for almost 20 years. Strict typing the way it is now would radically change these semantics overnight, and will make the adoption of strict a much bigger headache than it can be, as I believe Rasmus demonstrated. I think addressing these issues could get us a LOT closer to consensus and make a lot of those who voted 'no' on v0.3 vote yes on v0.4. Thanks for your consideration. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Mon, Feb 16, 2015 at 8:56 PM, Dmitry Stogov dmi...@zend.com wrote: I would propose exactly Andrea's 0.1. Most people were agree to support weak type hints by default. This proposal won't prevent feature addition of optional strict type hints. Sorry, but I'll have to repeat what has been said over and over again - the 0.1 version did not have overwhelming support and quite a lot of people aren't OK with (only) weak type hints. Part of the rationale behind the 0.2+ versions was that it would be unfair to strict typing supporters if weak is accepted alone. I agree with that on 100% (although I didn't agree with the proposed solution) and it's not hard to imagine why ... Also, IMO the only way a weak-types addition will NOT prevent strict type-hints in the future is to use the foo((type) $bar) syntax that was proposed by Anthony Ferrara 2 years ago. The syntax itself being different from that of already existing class type-hints implies both that it's a weak hint and that strict typing is expected to be available in the future (although I see no reason to delay it). In no other way excluding weird strict/weak modes or a regexp-like syntax will you be able to add both features. All are tired from endless arguing. That's not a reason to force-in a feature until it's clear that it is what we all (or at least most) really want. I hated seeing so much people supporting a proposal that they admit to not like, just so we have something at all - I don't believe that's the right approach, especially coming from tech people. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Am 16.02.2015 um 21:39 schrieb François Laupretre: If we deprecate using bare class names as type hints and replace it with the 'object(classname)' syntax, we can reserve keywords for 7.0 and, maybe 7.1 but potential name clashes should be away in 7.2. This is a huge BC break and will always clash with existing type hints. Also I think this will reduce readability and the gain is only very limit. We should introduce the type hints case-sensitive (lower case), so people can have their Integer and String classes without a clash. Most people use upper case class names already. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Le 16/02/2015 23:50, François Laupretre a écrit : So, IMO, the RFC is dead, whatever 2/3 or 3/4 we may have. Once it was clear that both camps would never agree, with every PHP founders against it, pushing it was useless. We're not electing a president, we're trying to ensure we make the right decision. The spirit is not the same. Hi, Does it mean that in your mind the founders of the PHP language (basically Rasmus/Zeev/Andy) have a veto right on any RFC just because they are the founders, like in a company with shareholders? If out of 100 votes for a feature, 97 were pro but the 3 founders votes were against then the RFC is moot? What about the voters that have been actively making PHP alive in the last 4 years and that have more commits in PHP than the founders themselves? Their opinion is of less value than the founders' just for historical reasons? Do you really think the new developers that arrived in the last years (and yes Andrea was one of them) are less skilled, less clever and have less vision than the founders had 15 years ago? I think your reasoning is flawed, sorry :) Regards Pascal Chevrel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Might I remind everyone that time is not on our side here - feature freeze is looming and actual work has to be done. The part you must understand is: Strict type hints are possible if someone cares to implement them with a next RFC. Be our guest. Right now we need to sort out the basic stuff - the missing numeric/mixed/resource hints, the ability to define mixed hints and make it all consistent. Maybe even fix/change some of conversion rules as a result (i'm just giving an example here). Gives us some time to gather our thought, discuss stuff and do the update to the RFC. Asuming stuff and pointing fingers before new version is out is just distracting.
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 12:58 AM, Sara Golemon poll...@php.net wrote: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. If nobody else does it, I will. I think Andrea's 0.3 proposal was extremely well balanced, served everyone's needs whether they would admit it or not, and who's only failing (subjectively termed) was the use of declare(). I think declare() is fine and not nearly as ugly as some have slandered it to be, but I'm willing to read the winds and modify it for v0.4. Straw poll: 1) ?php strict; 2) ?php-strict 3) use strict; (psuedo-namespace) 3) ?php // strict (I don't actually like HHVM's style, but if you do...) 4) declare(strict=true); (As a top-level declare only) 5) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) 6) your write-in vote here I'm not going to scope in union types, nullables, or falsables. We can leave that for a followup RFC, this one is contentious enough as it is. Thank you for taking over. I like use strict and declare as top-level only most. The ?php strict variants feel too ad-hoc. Nikita