Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Zeev, Dmitry and Francois (and anyone), I have a question on a specific conversion. There has been *a lot* of email about scalar types so I apologize if this is answered somewhere already. It seems that `float - bool` is always disallowed. If I am correct `int - bool` is permitted for all values (not just 0 and 1), which means that floats which can be converted to integers without dataloss should also be permitted to be booleans. If a specific float can be converted to an int, and all ints can be converted to booleans, then the transitive property should hold for that float to a bool. Am I understanding the current rules correctly? If so can I get more rationale on this? Cheers, Levi Morrison -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On Mar 14, 2015, at 13:37, Levi Morrison le...@php.net wrote: It seems that `float - bool` is always disallowed. If I am correct `int - bool` is permitted for all values (not just 0 and 1), which means that floats which can be converted to integers without dataloss should also be permitted to be booleans. If a specific float can be converted to an int, and all ints can be converted to booleans, then the transitive property should hold for that float to a bool. The problem there is what does without dataloss mean? At which precision do you consider there to be no dataloss? -Rasmus smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 14 March 2015 at 02:50, Rasmus Lerdorf ras...@lerdorf.com wrote: The problem there is what does without dataloss mean? At which precision do you consider there to be no dataloss? -Rasmus without dataloss would mean you can go from typeA - typeB - typeA' and typeA === typeA' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On Fri, Mar 13, 2015 at 10:31 PM, Levi Morrison le...@php.net wrote: On Fri, Mar 13, 2015 at 8:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On Mar 14, 2015, at 13:37, Levi Morrison le...@php.net wrote: It seems that `float - bool` is always disallowed. If I am correct `int - bool` is permitted for all values (not just 0 and 1), which means that floats which can be converted to integers without dataloss should also be permitted to be booleans. If a specific float can be converted to an int, and all ints can be converted to booleans, then the transitive property should hold for that float to a bool. The problem there is what does without dataloss mean? At which precision do you consider there to be no dataloss? Ah, I reread part of the RFC. It appears `float - int` is unchanged from current. This only confuses me more, though. If int - float is permitted, and float - int is permitted, I do not understand why float - bool is not permitted. Can someone clarify this? I apologize; my hands didn't keep up with my brain. I meant that if `int - bool` is permitted, and `float - int` is permitted, then by transitive property I would expect `float - bool` to be permitted. Can someone clarify why this is not the case? The RFC does not appear to justify this behavior (that I can find, anyway). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On Fri, Mar 13, 2015 at 8:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On Mar 14, 2015, at 13:37, Levi Morrison le...@php.net wrote: It seems that `float - bool` is always disallowed. If I am correct `int - bool` is permitted for all values (not just 0 and 1), which means that floats which can be converted to integers without dataloss should also be permitted to be booleans. If a specific float can be converted to an int, and all ints can be converted to booleans, then the transitive property should hold for that float to a bool. The problem there is what does without dataloss mean? At which precision do you consider there to be no dataloss? Ah, I reread part of the RFC. It appears `float - int` is unchanged from current. This only confuses me more, though. If int - float is permitted, and float - int is permitted, I do not understand why float - bool is not permitted. Can someone clarify this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Hi Zeev,
On Thu, Mar 12, 2015 at 12:10 AM, Zeev Suraski z...@zend.com wrote:
The latest version of the RFC includes changes discussed on internals@
last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
2. Accept leading/trailing spaces in string-number conversions.
wiki.php.net/rfc/coercive_sth
wiki.php.net/rfc/coercive_sth#vote
Status should be changed to voting. It's under discussion now.
It's not nice to have 2 modes for new feature while we can do it in a
single mode.
BC matters, but cleaner and simpler design would bring more benefits for
both PHP
users and developers. There is enough time to adopt for users.
The default behavior is better with this RFC. Weak mode defined in other
RFC is too
weak to be useful while strict mode seems too restrictive.
e.g.
?php
function check_num_range(int $num) { if ($num 0 || $num 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now br /'; // But $num could have any string.
//
check_num_range((int)$num) wouldn't help also.
?
If we decide to have even more stricter hint in the future, we may decide
to use strict
mode with this RFC. This is more preferable path for PHP being type aware.
IMHO.
For these reasons, I voted yes for this, no for the other.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
-Original Message- From: Ole Markus With [mailto:olemar...@olemarkus.org] Sent: Thursday, March 12, 2015 10:10 AM To: Pierre Joye; Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints On 03/11/2015 09:05 PM, Pierre Joye wrote: On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Voted no for the following reasons: - change default casting, which has been working since years, consistently inconsistent - due to the previous nature of changes, we have no way to be sure we won't break anything badly out there - big changes in the RFC+patch between last discussions and vote. Should not be allowed, can't veto it so voted no I changed my vote to no for the same reasons. I'm sorry to hear that Ole Markus. I do want to address these concerns: - change default casting, which has been working since years, consistently inconsistent - due to the previous nature of changes, we have no way to be sure we won't break anything badly out there Casting rules aren't touched - it's rules for internal function arguments that are changed. This has been a key premise of this proposal since the beginning; Contrary to the 2nd statement, we have a pretty good way of knowing it won't break things badly out there - running it with real world apps and our test suite. As the Impact On Real World Applications section suggests (wiki.php.net/rfc/coercive_sth#changes_to_internal_functions) - the real world impact is minimal, since the conversion which are blocked are rarely relied upon in apps. The issues you do get are almost always legitimate issues - with excellent signal to noise ratio. Users would have several YEARS to fix these issues before they become errors and not warnings. Many of the compatibility breakages we've done over the years (and in 7) had / would have a lot farther reaching impact - often with zero end-user gain to show for it. What is being consistently ignored by everyone is the fact that large projects - with the absence of having a good dynamic option - are likely to implement strict project-wide, resulting in WAAAY bigger breakage, since the strict mode does not differentiate between sensible conversions, that have been relied upon in PHP for the last 20 years (32 - 32) and nonsensible conversions that are for the most part a side effect of implementation (100 dogs - 100). - big changes in the RFC+patch between last discussions and vote. Should not be allowed, can't veto it so voted no There have been NO big changes to the proposal - only two tweaks which I clearly detailed in the Vote email, that have been publicly discussed in detail on internals@ more than a week ago. There is absolutely no rule in the voting RFC that requires a long period of time between the last changes to the RFC and the vote. The mandatory discussion period starts ticking when the RFC is sent to the list, not when the last changes are made to it. Anyone claiming otherwise is misleading, as both the text in wiki.php.net/rfc/voting#discussion_period is clear about when the ticking starts - and on top of that, I can tell you as the person who introduced the mandatory discussion period and wrote that text, that resetting the clock on every change to the RFC was never ever even remotely considered or intended as a requirement. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 03/11/2015 09:05 PM, Pierre Joye wrote: On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Voted no for the following reasons: - change default casting, which has been working since years, consistently inconsistent - due to the previous nature of changes, we have no way to be sure we won't break anything badly out there - big changes in the RFC+patch between last discussions and vote. Should not be allowed, can't veto it so voted no I changed my vote to no for the same reasons. Cheers, Ole Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
In addition, I'm voting no for the following reasons (in addition to Dan's): 1. It downplays the BC breaks. It says: Given the change to the acceptable values into a wide range of internal functions, this RFC is likely to result in a substantial number of newly introduced E_DEPRECATED warnings in internal function invocations, although those can be easily suppressed So BC breaks are fine, as long as they are *easily suppressed*. This is madness, as they won't be able to be suppressed in 8 (when they will be turned into hard breaks). If you copied the whole paragraph (one more sentence) instead of it out of context it would be clear that we're not at all downplaying anything. We're portraying it exactly for what it is, for better or worse. The fact users would have years to adjust is radically different from if we broke compatibility overnight, and that's exactly what this paragraph conveys. 2. It judges the BC breaks based on skeleton applications (Drupal 7's stock home page, Drupal 7's stock admin interface, Magento's home page, Wordpress's home page, ZF2's skeleton app, Symfony's ACME app). It doesn't bring up unit tests (which Symfony was shown to have many failures). It doesn't show running on non-framework code. It doesn't show the average Wordpress/Drupal module for example. I don't consider Drupal/Magento or WordPress framework code. It's real world apps, very very similar to other custom-coded real world apps. 3. It contains massive misinformation. It is our position that there is no difference at all between strict and coercive typing in terms of potential future AOT/JIT development - none at all. It's our position, the position of people very well versed in this area that have written a JIT compiler that runs blazingly fast with no type hints at all. It's fine that you have a different opinion. One of us is wrong. Yet the JavaScript community is discovering the exact opposite, and is looking into a extremely similar dual-mode: https://developers.google.com/v8/experiments This is hardly the exact opposite. It means something we agreed on from the get go - if you *change* your code so that the compiler can gain more insight on what the types are during compile-time (e.g. an explicit cast, or if we add typed variable declarations) - then sure, there'll be AOT/JIT gains - but they're absolutely not coming from the difference in type hints. I still contend that with coercive type hints we can perform the exact same static analysis, with just differently phrased output such as it may need to be converted rather than will be rejected. Identical type inference rules. Identical everything, just slightly modified text. 4. It makes claims against the [dual mode RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this RFC. For example: Too strict may lead to too lax. In the Dual Mode RFC, when in Strict mode, in many cases, functions would reject values that, semantically, are acceptable. For example, a “32” (string) value coming back from an integer column in a database table, would not be accepted as valid input for a function expecting an integer. Since semantically the developer is interested in this argument-passing succeeding, they would have the choice of either removing the integer STH altogether, or, more likely, explicitly casting the value into an integer. This would have the opposite of the desired outcome of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, and would happily convert “100 dogs”, “Apples” and even arrays and booleans into an integer. Further, since already today, internal functions employ coercion rules that are more restrictive than PHP's explicit casting, pushing people towards explicit casting will actually make things worse in case developers opt for explicit casting as they pass values in an internal function call. Yet it completely ignores the fact that the identical situation appears with the coercive mode RFC. The difference is that with Dual-Mode, it's 100% opt- in, where with coercive you're forced to add casts. That's one difference, but the real difference is that the rules are radically - and the coercive ones are what you'd almost always want to use in real life, while strict almost never is - which means a lot more explicit casts. The most popular conversion in PHP - string - number - just works. With strict mode, it simply doesn't. Personally, I think that the 'it won't break until you actually flip it on' stance is weak. When people do flip it on (and they'd certainly be encouraged to do so by many people, e.g. your blog post from a few weeks ago) - they're going to see massive breakage which will in turn require massive explicit casting - resulting in much worse code than in the coercive type hints case. 5. It's full of logical inconsistencies: For example, given the following code: function foo(bool
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 12/03/15 08:29, Zeev Suraski wrote: There have been NO big changes to the proposal - only two tweaks which I clearly detailed in the Vote email, that have been publicly discussed in detail on internals@ more than a week ago. Zeev ... being realistic I think that the chances of getting another 48 votes in favour are unlikely as are the chances of blocking the other proposal? The problem here is that a large number of people want type hinting one way or another and there is not a strong enough case being made NOT to bow to that will? So the next problem is perhaps how do we live with a section of the developer world adding hints to well established libraries? During the move to PHP5 one could quite happily write code that continued to work on the majority of PHP4 systems, The move to PHP7 needs the same set of guidelines, so what is currently being championed which will mean that we have to maintain a PHP5 version of a library from day one of PHP7 and what do we avoid in order for PHP code still to run on PHP5? I still have to be convinced that adding a half baked variable check does have a major advantage. YOU have demonstrated the various transfer paths although they lacked the finer detail type checking that already happens in many code bases such as the range of the number passed. The bit I am more concerned about is the further dilution of the docblock annotation as people will adopt type hints in place of the already existing annotation and again we loose a lot more than we gain :( Personally I would much prefer that this was picked up properly again as other RFC's are trying to do, and I feel that answers all of the type hinting ad other static analysis problems that some people seem to think are so important. Expansion of the docblock 'standard' will also allow range of variables to be managed, yet the whole lot can be striped and ignored once one is out of 'design' phase. Is the final endpoint target here that like python, PHP will become a two stage process with compiled versions of user land code? -- 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] [VOTE][RFC] Coercive Scalar Type Hints
On 3/12/15 4:11 AM, Lester Caine wrote: On 12/03/15 08:29, Zeev Suraski wrote: There have been NO big changes to the proposal - only two tweaks which I clearly detailed in the Vote email, that have been publicly discussed in detail on internals@ more than a week ago. Zeev ... being realistic I think that the chances of getting another 48 votes in favour are unlikely as are the chances of blocking the other proposal? The problem here is that a large number of people want type hinting one way or another and there is not a strong enough case being made NOT to bow to that will? So the next problem is perhaps how do we live with a section of the developer world adding hints to well established libraries? During the move to PHP5 one could quite happily write code that continued to work on the majority of PHP4 systems, The move to PHP7 needs the same set of guidelines, so what is currently being championed which will mean that we have to maintain a PHP5 version of a library from day one of PHP7 and what do we avoid in order for PHP code still to run on PHP5? Code with type hints won't be valid on PHP 5 period, no matter what approach we take. Making internal functions pickier about their existing typing doesn't make writing PHP5-compatible code impossible, it just means you have to be more careful about weird and probably-buggy cases like number_format(101 dalmatians). As Zeev noted, most of the places that these changes caused an issue are likely existing bugs in the first place, so the PHP 5 code would become better by being PHP 7-compatible. The bit I am more concerned about is the further dilution of the docblock annotation as people will adopt type hints in place of the already existing annotation and again we loose a lot more than we gain :( Personally I would much prefer that this was picked up properly again as other RFC's are trying to do, and I feel that answers all of the type hinting ad other static analysis problems that some people seem to think are so important. Expansion of the docblock 'standard' will also allow range of variables to be managed, yet the whole lot can be striped and ignored once one is out of 'design' phase. We don't lose anything by type information moving from a docblock to the method signature itself, and in fact we gain a great deal as has been discussed to death in this thread. We already can have whatever type information you want in docblocks, but that means diddlysquat for the compiler or runtime. This whole paragraph is a red herring. Is the final endpoint target here that like python, PHP will become a two stage process with compiled versions of user land code? With an opcache built into core and discussion of it moving into the engine I think that's a given, in practice. That's entirely unrelated to typing, though. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 12/03/15 16:55, Larry Garfield wrote: On 3/12/15 4:11 AM, Lester Caine wrote: On 12/03/15 08:29, Zeev Suraski wrote: There have been NO big changes to the proposal - only two tweaks which I clearly detailed in the Vote email, that have been publicly discussed in detail on internals@ more than a week ago. Zeev ... being realistic I think that the chances of getting another 48 votes in favour are unlikely as are the chances of blocking the other proposal? The problem here is that a large number of people want type hinting one way or another and there is not a strong enough case being made NOT to bow to that will? So the next problem is perhaps how do we live with a section of the developer world adding hints to well established libraries? During the move to PHP5 one could quite happily write code that continued to work on the majority of PHP4 systems, The move to PHP7 needs the same set of guidelines, so what is currently being championed which will mean that we have to maintain a PHP5 version of a library from day one of PHP7 and what do we avoid in order for PHP code still to run on PHP5? Code with type hints won't be valid on PHP 5 period, no matter what approach we take. Making internal functions pickier about their existing typing doesn't make writing PHP5-compatible code impossible, it just means you have to be more careful about weird and probably-buggy cases like number_format(101 dalmatians). As Zeev noted, most of the places that these changes caused an issue are likely existing bugs in the first place, so the PHP 5 code would become better by being PHP 7-compatible. If type hinting is NOT used at all, then the code should run on PHP5? The question is just what does one have to avoid to remain PHP5 compatible, and more important just how does one avoid some third party use of it getting in the way. The bit I am more concerned about is the further dilution of the docblock annotation as people will adopt type hints in place of the already existing annotation and again we loose a lot more than we gain :( Personally I would much prefer that this was picked up properly again as other RFC's are trying to do, and I feel that answers all of the type hinting ad other static analysis problems that some people seem to think are so important. Expansion of the docblock 'standard' will also allow range of variables to be managed, yet the whole lot can be striped and ignored once one is out of 'design' phase. We don't lose anything by type information moving from a docblock to the method signature itself, and in fact we gain a great deal as has been discussed to death in this thread. We already can have whatever type information you want in docblocks, but that means diddlysquat for the compiler or runtime. This whole paragraph is a red herring. The whole argument about adding type hinting revolves about red herrings. There is nothing stopping someone using static analysis on well written and documented PHP5 code today without affecting everybody elses use of that code. Is the final endpoint target here that like python, PHP will become a two stage process with compiled versions of user land code? With an opcache built into core and discussion of it moving into the engine I think that's a given, in practice. That's entirely unrelated to typing, though. Again much is being made of 'optimizing at compile time' a term which I simply don't recognise. If one has a script that is running ... it's running ... and loading it up with more switches is detracting from performance ... unless there is caching already running? -- 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] [VOTE][RFC] Coercive Scalar Type Hints
Voting no due to:
i) Having conversion rules be difference in userland to internal functions.
You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This is a massive cognitive
load, and will be one of those issues that catches users out again and
again. Why on earth should a boolean be convertible to int for some
functions but not others?
What will happen when someone writes code that extends an internal
class and overrides one of the functions, is that the person who is
using that extended class will have to alter their code to use the
extended class in a different way to how they would use the built in
class directly.
For everyone who didn't pick this up in the RFC, it's hidden in the
large chunk of text:
Unlike user-land scalar type hints, internal functions will accept
nulls as valid scalars.
ii) The subtle BC breaks.
false - int # No more conversion from bool
true - string # No more conversion from bool
btw You appear to have only tested this code against barebones
frameworks. These are often written far more cleanly than actual
applications so I don't think the report of 'very limited' BC breaks
is accurate.
iii) Having conversion work, except when they don't. People who want
weak type hints want weak type hints - they don't want code that
breaks unexpectedly.
function foo(int $bar){...}
foo(36/$value);
// works when $value = 1, 2, 3, 4 breaks when $value = 5
This is neither weak nor strict type - this is a horrible hybrid that
would only catch people out.
But finally, the fact that a significant part of the RFC is talking
about how the behaviour will need to be cleaned up in a future RFC,
but at the same time that some of the problems will be left for five
years show that this isn't a sensible RFC to vote for, even for the
people who just want weak types
cheers
Dan
.
On 11 March 2015 at 15:10, Zeev Suraski z...@zend.com wrote:
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@ last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
2. Accept leading/trailing spaces in string-number conversions.
wiki.php.net/rfc/coercive_sth
wiki.php.net/rfc/coercive_sth#vote
Thanks!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Zeev, Considering that there has not been any discussion of your final proposal (since the last change), I think putting it to vote prior to having the ability to test or discuss is extremely problematic. Especially considering every time we tried to test the proposal or discuss it before you said that you needed to tweak the rules. Now opening vote without giving the ability for people to test it or discuss prior to voting is extremely bad form. I **strongly** suggest that you retract the vote and open discussion on the final proposal. Anthony On Wed, Mar 11, 2015 at 11:10 AM, Zeev Suraski z...@zend.com wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On Wed, 11 Mar 2015, Zeev Suraski wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. Aren't you supposed to leave it one week between annoucing the latest RFC with your changes, and the real vote? Actually, now I read it, it should actually be two weeks ... but then I guess it was just a tweak on an earlier version: https://wiki.php.net/rfc/voting#discussion_period cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Anthony, While I only put in the final changes today, they're identical to what I said was going to be done on the discussion thread a week+ ago, there was no further feedback or discussion on these changes. The patch (minus these two minor changes) has been available for over a week. I think we've had enough drama with scalar type hints already and it's time for closure. Let's let the two votes go through and finally get clarity. If people find big rejects on the tweaked patch which requires substantial meaningful changes - I'll restart the vote if necessary. Thanks, Zeev -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Wednesday, March 11, 2015 5:20 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints Zeev, Considering that there has not been any discussion of your final proposal (since the last change), I think putting it to vote prior to having the ability to test or discuss is extremely problematic. Especially considering every time we tried to test the proposal or discuss it before you said that you needed to tweak the rules. Now opening vote without giving the ability for people to test it or discuss prior to voting is extremely bad form. I **strongly** suggest that you retract the vote and open discussion on the final proposal. Anthony On Wed, Mar 11, 2015 at 11:10 AM, Zeev Suraski z...@zend.com wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Hi, Derick Rethans der...@php.net writes: On Wed, 11 Mar 2015, Zeev Suraski wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. Aren't you supposed to leave it one week between annoucing the latest RFC with your changes, and the real vote? I'm reading that the delay is one week after announcing the intent to vote. Which means that the RFC is in final state before voting, and the author has announced intention to vote. I haven't seen the mail announcing this, did I miss it? There were a lot of mails on internals lately, it may be possible. If this mail wasn't sent, should the rules be different because there was a lot of debate on this RFC? Then which other rule should be broken? Actually, now I read it, it should actually be two weeks ... but then I guess it was just a tweak on an earlier version: https://wiki.php.net/rfc/voting#discussion_period I guess that since there was a lot of discussion, shortening to one week makes sense. cheers, Derick Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
All,
On Wed, Mar 11, 2015 at 11:52 AM, Dan Ackroyd dan...@basereality.com wrote:
Voting no due to:
i) Having conversion rules be difference in userland to internal functions.
You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This is a massive cognitive
load, and will be one of those issues that catches users out again and
again. Why on earth should a boolean be convertible to int for some
functions but not others?
What will happen when someone writes code that extends an internal
class and overrides one of the functions, is that the person who is
using that extended class will have to alter their code to use the
extended class in a different way to how they would use the built in
class directly.
For everyone who didn't pick this up in the RFC, it's hidden in the
large chunk of text:
Unlike user-land scalar type hints, internal functions will accept
nulls as valid scalars.
ii) The subtle BC breaks.
false - int # No more conversion from bool
true - string # No more conversion from bool
btw You appear to have only tested this code against barebones
frameworks. These are often written far more cleanly than actual
applications so I don't think the report of 'very limited' BC breaks
is accurate.
iii) Having conversion work, except when they don't. People who want
weak type hints want weak type hints - they don't want code that
breaks unexpectedly.
function foo(int $bar){...}
foo(36/$value);
// works when $value = 1, 2, 3, 4 breaks when $value = 5
This is neither weak nor strict type - this is a horrible hybrid that
would only catch people out.
But finally, the fact that a significant part of the RFC is talking
about how the behaviour will need to be cleaned up in a future RFC,
but at the same time that some of the problems will be left for five
years show that this isn't a sensible RFC to vote for, even for the
people who just want weak types
cheers
Dan
In addition, I'm voting no for the following reasons (in addition to Dan's):
1. It downplays the BC breaks. It says:
Given the change to the acceptable values into a wide range of
internal functions, this RFC is likely to result in a substantial
number of newly introduced E_DEPRECATED warnings in internal function
invocations, although those can be easily suppressed
So BC breaks are fine, as long as they are *easily suppressed*.
This is madness, as they won't be able to be suppressed in 8 (when
they will be turned into hard breaks).
2. It judges the BC breaks based on skeleton applications (Drupal 7's
stock home page, Drupal 7's stock admin interface, Magento's home
page, Wordpress's home page, ZF2's skeleton app, Symfony's ACME app).
It doesn't bring up unit tests (which Symfony was shown to have many
failures). It doesn't show running on non-framework code. It doesn't
show the average Wordpress/Drupal module for example.
3. It contains massive misinformation.
It is our position that there is no difference at all between
strict and coercive typing in terms of potential future AOT/JIT
development - none at all.
And
It is the position of several Strict STH proponents that Strict
STH can help static analysis in certain cases. For the same reasons
mentioned above about JIT, we don't believe that is the case -
although it's possible that Strict Typing may be able to help static
analysis in certain edge cases. However, it is our belief that even if
that is true, Static Analyzers need to be designed for Languages,
rather than Languages being designed for Static Analyzers.
Yet the JavaScript community is discovering the exact opposite,
and is looking into a extremely similar dual-mode:
https://developers.google.com/v8/experiments
4. It makes claims against the [dual mode
RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this
RFC. For example:
Too strict may lead to too lax. In the Dual Mode RFC, when in
Strict mode, in many cases, functions would reject values that,
semantically, are acceptable. For example, a “32” (string) value
coming back from an integer column in a database table, would not be
accepted as valid input for a function expecting an integer. Since
semantically the developer is interested in this argument-passing
succeeding, they would have the choice of either removing the integer
STH altogether, or, more likely, explicitly casting the value into an
integer. This would have the opposite of the desired outcome of strict
STHs - as explicit casts ($foo = (int) $foo;) always succeed, and
would happily convert “100 dogs”, “Apples” and even arrays and
booleans into an integer. Further, since already today, internal
functions employ coercion rules that are more restrictive than PHP's
explicit casting, pushing people towards explicit casting will
actually make things worse in case developers opt for explicit casting
as they pass values in an internal
RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
-Original Message-
From: Dan Ackroyd [mailto:dan...@basereality.com]
Sent: Wednesday, March 11, 2015 5:53 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Voting no due to:
i) Having conversion rules be difference in userland to internal
functions.
You list 'Single Mode' as a benefit of this RFC, but it's only single mode
if you
gloss over this difference. This is a massive cognitive load, and will be
one of
those issues that catches users out again and again. Why on earth should a
boolean be convertible to int for some functions but not others?
Bool-int is not allowed across the board. Yes, in 7 internal functions
will emit E_DEPRECATED and userland will reject, but that's a transition
period but the rules are the same for both.
What will happen when someone writes code that extends an internal class
and overrides one of the functions, is that the person who is using that
extended class will have to alter their code to use the extended class in
a
different way to how they would use the built in class directly.
For everyone who didn't pick this up in the RFC, it's hidden in the large
chunk
of text:
Unlike user-land scalar type hints, internal functions will accept nulls
as valid
scalars.
NULLs are a different case, that's true, but it actually can be resolved in
the future (as is mentioned in the RFC). The key problem with rejecting
NULLs for internal functions in the same way they are for userland is that
this is the standard way you can denote an 'empty' argument. E.g.,
mysqli_connect(null, $username, $password). The problem is that function
implementations rely on coercion of null-string and treat empty strings as
if no argument was supplied. We can easily change it so that these function
explicitly accept NULLs (which is already a supported modifier for ZPP), and
then have explicit handling for NULL as a non-argument. Since it requires
many changes in extension code - that's something that's probably too big
for us to pull off for 7.0, but we can most probably do it for 7.1. Also,
if we accept nullable type hints
(https://wiki.php.net/rfc/nullable_types_rfc) the discrepancy will
practically disappear, as you'd be able to denote an int/null hint in the
very same way you can do it for internal functions.
ii) The subtle BC breaks.
false - int # No more conversion from bool
true - string # No more conversion from bool
That's fair; I think the breakage is very limited and worth the gains, but
that's obviously subjective. Clearly, going for a single mode and making it
stricter than what we have today does mean some level of compatibility
breakage by definition - each person should form their opinion on whether
that's worth it or not.
btw You appear to have only tested this code against barebones
frameworks. These are often written far more cleanly than actual
applications so I don't think the report of 'very limited' BC breaks is
accurate.
I don't view Magento, Drupal and Wordpress aren't barebones frameworks.
They're pretty full featured real world apps (that also happen to be
frameworks).
iii) Having conversion work, except when they don't. People who want weak
type hints want weak type hints - they don't want code that breaks
unexpectedly.
function foo(int $bar){...}
foo(36/$value);
// works when $value = 1, 2, 3, 4 breaks when $value = 5
This is neither weak nor strict type - this is a horrible hybrid that
would only
catch people out.
Ultimately it's all about a signal to noise ratio. I think that strict STH
has horrible signal to noise ratio; Weak type hints can easily allow
problematic values to be glossed over and accepted - so there's zero noise,
but also zero signal in case of trouble. This RFC proposes a rule-set that
has very good signal to noise ratio, but of course, there are edge cases
here and there. Personally, I don't feel that all the x div y examples that
were/are commonly brought up in the context of float/int conversions are
very real world, but rather, such edge cases - but here too, each person can
form their opinion about it...
It seems a key thing you don't like about the RFC is that it's transitional
(what you call 'cleanup'). That's fair, but personally, I think that going
through a transition period that on one hand allows both our codebase and
more importantly our users' codebase to evolve - and that ultimately results
in one, consistent language behavior is better than the alternatives (two
modes that will never ever converge).
Either way, thanks for the feedback!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Thanks! Zeev
RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
-Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: Wednesday, March 11, 2015 5:57 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints On Wed, 11 Mar 2015, Zeev Suraski wrote: Aren't you supposed to leave it one week between annoucing the latest RFC with your changes, and the real vote? Actually, now I read it, it should actually be two weeks ... but then I guess it was just a tweak on an earlier version: https://wiki.php.net/rfc/voting#discussion_period That period is between the RFC is brought up on the list and when the voting starts. It doesn't say anywhere that there's a mandatory discussion period after the last change on the RFC. The mandatory two week discussion period includes changes to the RFC as a part of the discussion cycle and doesn't reset on every change. It was announced on internals almost 3 weeks ago, by one of the authors, as a concrete RFC to be voted on for PHP 7.0. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
-Original Message- From: Dan Ackroyd [mailto:dan...@basereality.com] Sent: Wednesday, March 11, 2015 8:04 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints On 11 March 2015 at 16:45, Zeev Suraski z...@zend.com wrote: I think that going through a transition period ... that ultimately results in one, consistent language behavior This RFC is explicitly saying that there is stuff that will be need to be changed in the future. Why would anyone upgrade from PHP 5.6 to PHP 70 when there are going to be more changes to the type system? Because of the huge performance gain? And the many features? And the ability to gradually prepare for future versions softly, like virtually all of our deprecated functionality lifecycle works? This is clearly worse than the strict STH RFC; with that people can write code that will work on 5.x, 7 and 7.x by just not using scalar type hints. That's exactly the same here too. Code that works on 7 will work on 5 - 7 will be more restrictive than 5, but not vice versa, so anything that works on 7, works fine on 5. And you get the benefit of weeding out issues and make your code better for both versions by checking it on 7. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 11 March 2015 at 16:45, Zeev Suraski z...@zend.com wrote: I think that going through a transition period ... that ultimately results in one, consistent language behavior This RFC is explicitly saying that there is stuff that will be need to be changed in the future. Why would anyone upgrade from PHP 5.6 to PHP 70 when there are going to be more changes to the type system? Everyone would wait until that future version of PHP to upgrade and so just have to do a single migration, instead of having to do two migrations? This is clearly worse than the strict STH RFC; with that people can write code that will work on 5.x, 7 and 7.x by just not using scalar type hints. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Voted no for the following reasons: - change default casting, which has been working since years, consistently inconsistent - due to the previous nature of changes, we have no way to be sure we won't break anything badly out there - big changes in the RFC+patch between last discussions and vote. Should not be allowed, can't veto it so voted no Thanks! Zeev
