> -----Original Message----- > From: Pádraic Brady [mailto:padraic.br...@gmail.com] > Sent: Wednesday, February 18, 2015 4:50 PM > To: Andrey Andreev > Cc: Zeev Suraski; Nikita Popov; Rasmus Lerdorf; Sara Golemon; PHP > internals > Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 > > Hi all, > > On 18 February 2015 at 09:14, Andrey Andreev <n...@devilix.net> wrote: > > Hi, > > > > On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski <z...@zend.com> wrote: > >> I am wondering what the point is indeed with preventing "123" to 123. > >> So far, all the concrete use cases people brought up had to do with > >> "Apple" or > >> "100 dogs", but nobody ever seems to be able to explain why converting > "123" > >> to 123 is likely to be a problem real world. Is it really just > >> static analyzers? > >> > > > > I too am curious about the potential issue with "123" to 123 > > specifically, although it could be seen as a subset of another problem > > that is solved with strict hints - numeric-character string > > identifiers being erroneously treated as integers. > > However, “123” is exceptional. It’s redefining an integer as “ an integer > or a > string comprised wholly of digits without leading zeroes, with an optional > leading hyphen, and representing an integer up to PHP_INT_MAX”, i.e. an > integer or a string with a real number that be made an integer without > loss. > No other string need apply. That’s not strict-strict typing (there’s > coercion) > but it’s probably strict enough to pass muster (it’s one single obvious > coercion under limited circumstances).
> Then again, it’s an exception that requires a long sentence. There are shorter ways to define this exception - not in a formal way perhaps, but that gets the point across - something like 'a string that looks like an integer', and we can throw in 'and that can be converted with no data loss'. Of course, writing docs isn't one of my strong points :) > It’s just not clear, > to me, if this is the sole intended exception, or if that sentence needs > to be > expanded to a paragraph. A section? Are we going to need a chapter? I’m > assuming octals-in-a-string are a no-go to be coerced whereas others might > just see an integer with superfluous leading zeroes. It's not the sole exception, but it's one of the most important one in my opinion. The rationale would be conversions that can be made without meaningful data loss or creating data that wasn't there. That means that "42" can coerce into int, and "42.2" can coerce into float, and int can coerce into float - but not vice versa. That means that boolean will not coerce into anything, because turning it into an integer, float or string 'invents' data that wasn't there. A somewhat sticky points is coercion into boolean. We need to figure this one out, and hopefully we can come up with something most people can agree to. Another open question would be coercion of float/int into string. This particular point might be good for a secondary vote, as I imagine people from both camps won't see this particular conversion as a major deal-breaker for them (could be wrong). Getting the point across could be made using a table very similar to the one in wiki.php.net/rfc/scalar_type_hints#behaviour_of_weak_type_checks (as you seemed to suggest) - of course modified to reflect the much stricter ruleset we're talking about here. I don't imagine that even a formal declaration would require a whole chapter. Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
