> De : Damien Tournoud [mailto:d...@damz.org]
>
> But anyway, that's not even the point. The point is that return values that
> "worked" in a world of transparent type-jungling will not work in a world
> of stricter typing checks. Which means that we need:
> 
> (1) To accept that for now casting FALSE to the empty string is the right
> thing to do;

No. Add an explicit for false. We want programs to be cleaner, not encourage 
casting.

> 
> until / unless:
> 
> (2) We fixed all the common functions in the standard library so that they
> stop returning inconsistent types, in particular in the cases where it
> should not even be a debate what is the right thing to do (for substr, if
> the arguments point to an empty slice, return the empty string).

That's history. Propose an RFC to fix substr() behavior (good luck :)

Yes, we propose to deprecate potentially-problematic behaviors. That's not 
because we are running behind Anthony's RFC, as some may believe, but we 
sincerely think, at the end, it will bring more good than bad to PHP overall. 
You will have at least 5 years to fix your code. PHP is evolving. You like it 
or not. If you don't, you vote against the feature. That's democracy, which is 
not always the case for other languages. Can I say more ?

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to