Hi Pavel, > -----Ursprüngliche Nachricht----- > Von: Pavel Kouřil [mailto:pajou...@gmail.com] > Gesendet: Sonntag, 22. Februar 2015 15:54 > An: Robert Stoll > Cc: Zeev Suraski; PHP internals > Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll <p...@tutteli.ch> wrote: > > > > I see the migration plan roughly as follows: > > > > PHP 7.0: > > - reserve keywords: bool, int, float including alternatives > > - deprecate alternative type names such as boolean, integer etc. > > > > - introduce new conversion functions which reflect the current behaviour > > of (bool), (int) etc. > > --> as mentioned above, they could be named oldSchoolBoolConversion > > etc. > > --> Encourage users to use this function instead of (bool), > > (int) etc since (bool) etc. will change with PHP 8.0. Also mention, > > that this function should only be used if the weakness is really > > required otherwise use the new conversion functions from below > > > > - introduce new conversion functions which reflect the new defined > > conversion rule set (which shall be the only one > encouraged in the future) Those functions shall trigger an E_RECOVERABLE_ERROR > > --> encourage users to use this functions instead of (bool), (int) > > and oldSchoolBoolConversion etc. (unless the weakness is really > > required, then use oldSchoolBoolConversion) > > > > - update the docs in order to reflect the new encouraged way. Also > > mention that: > > - (bool), (int) etc. will change their behaviour in PHP 8.0 > > - internal functions will use the new conversion rules if not already > > done this way in PHP 8.0 (for instance, strstr will no > longer accept a scalar as third parameter in the case where we do not support > implicit casts to bool) > > - operators will use the new conversion rules if not already done this > > way in PHP 8.0 > > - (control structures will use the new conversion rules if not > > already done this way in PHP 8.0) =>Maybe this is too strict for most > > of you and goes against the spirit of PHP (I suppose some of you will > > say that - fair enough, I guess you are right). In this case, I would > > at least use the term "loose comparison" as mentioned here: > > http://php.net/manual/en/types.comparisons.php#types.comparisions-loos > > e instead of using the term "conversion", then it is compatible with > > the changes introduced in PHP 8.0 > > > > PHP 7.1: necessary bug-fixes introduced with PHP 7.0 PHP 7.x: > > deprecate even more if required PHP 8: > > - introduce scalar type hints which reflect the conversion rules as > > defined (adding strict type hints as well is possible of > course, whether with an ini-setting, a declare statement or individually with > a modifier something like "strict int" for a single > parameter or strict function for all parameters incl. return type or strict > class for every type defined in the class is up to > discussion) > > - exchange the behaviour of (bool), (int) etc. -> use the new conversion > > rules instead > > - change internal functions which do not yet obey to the new conversion > > rules > > - change the operators which do not yet obey to the new conversion rules > > (for instance, + would also emit an > E_RECOVERABLE_ERROR for "a" + 1) > > - (change the control structures in order that they obey the new > > conversion rules as well) => as mentioned above, probably too strict > > for PHP > > > > Back to this RFC. think this RFC goes in the right direction with the > > specified conversion rules. Only thing to get rid of are > the implicit conversions to bool from string, float and int IMO. > > Moreover, I like that the RFC already has different steps for adding the > > new behaviour. Yet, I think it should slow down a > little bit as shown. I think we need more time to come up with a very good > strategic solution. > > > > Hello, > > Am I understanding correctly that you are suggesting changes to type casting? > This seems like a bad idea. Explicit and > implicit conversions are something really different. Generally, implicit > conversions are OK only when no data is lost and > explicit conversions (casts) are used when you realize some information can > get lost and you still want to proceed with the > conversion. Having only one type of conversion is IMHO weird.
Yes, I am suggesting to make conversions behave the same regardless if it is implicit or explicit. The only difference between the two should be that one is stated explicitly by the user where the other is applied implicitly. Other programming languages behave like this and are more predictable for users as well as developers because one does not need to learn two sets of conversion rules. > > Also, I'm not a fan of having to wait for scalar type hints for few more > years. :( > > Regards > Pavel Kouril > > -- > 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
