Re: Scalar Type Hints v0.4

Hi, On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre <francois@php.net> wrote: > Hi Andrey, > >> De : Andrey Andreev [mailto:narf@devilix.net] >> >> 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. > > Please give use cases. Do you want to support '0xhexa' strings ? that's > possible. We are not only restricting possible conversions, we can also support additional syntaxes. > Just give use cases for what you think should be enabled or disabled, compared to the current > behavior. > > The only change we have in list so far about (string -> number) is rejecting trailing chars > (but accepting trailing blanks). > > We are in the process of changing these rules so, please give examples of ' > numeric-character string identifiers being erroneously treated as integers'. If you mean > '7 years', it's in list already. If others, tell us. > >> That is especially bad when such identifiers are in fact generated as >> integers first so that they are incremental, but the >> program/database/business logic requires them to be fixed-length >> strings and/or in hexadecimal format. In such cases, even silently >> discarding leading zeros can prove to be problematic, while in the >> case of hexadecimal representations you'd need more than 10 data >> samples to notice the problem if you don't use a strict hint. > > Do you mean we should accept hexadecimal string as int ? why not ? Give exact syntax(es) you > want to support (except leading/trailing blanks, which are default now). > No, I meant the opposite ... I was trying to explain cases where a weak hint would be insufficient. Sorry for not including examples in my first mail, I did that in my next reply: > Consider the following signature: > > function foo(int $bar) {} > > In the case of a *string* representation of a hexadecimal number, the > following would error only on the last iteration with a weak hint, and > on the very first if it was a strict hint: > > for ($i = 0; $i < 11; $i++) > { > foo(base_convert($i, 10, 16)); > } > > And when I said leading zeros, I was talking about fixed-length string > identifiers such as '001', '002', etc. where you may *unintentionally* > pass such a value to a function that deals with ... quantities, for > example. A strict hint in that case would immediately catch this > logical error while a weak hint would silently ignore the leading > zeros and will happily treat the value as an integer. Again, the > precondition here is that it's not an integer value that happens to be > stored as a string, but a non-integer value that just looks like an > integer. Cheers, Andrey.