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-loose 
> 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.

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

Reply via email to