On 22/02/15 00:07, François Laupretre wrote: >>> 3. "1E07" might be construed as overly generous assuming we are >>> > > excluding stringy integers like hex, oct and binary >> > Yet again ... If we have to add a lot of extra checks then why can't we >> > simply ask if the data is a usable integer. At the end of the day it >> > does depend on where the data was sourced? Binary data is only usable if >> > we know that it is binary, or we will be converting some other format >> > anyway? > I asked you for rules to recognize octal. I am all in favor of recognizing > other numeric strings, hexa with leading 0x (detecting trailing h is more > ambiguous and slower), for instance. It was removed some weeks ago for > consistency reasons but it can be reintroduced in a consistent way in the > future if needed.
I've given the 'c' ones, but others have already blocked the use of them. Octal escape is allowed but a simple '0' or '0o' has the same problem as 0h or 0x ? Those of us still using 'c/c++' get used to the old standards. >>> > > 4. I'm assuming the stringy ints are rejected? >> > Source material may be 'stringy ints', so all that does is say "we can't >> > use the original variable it has to be converted" rather than we can and >> > use it's 'non-stringy' view. > Can you explain? I don't understand. I'm working with a 'variable' which may be an integer but that is only enforced by reference to how I am looking at it. I understand that some people want to ONLY allow it to be an integer and that may be the constraint added to it, but you may also need the string view, or the origin may be a string already, so one maintains both a binary view and a 'string' view of the same variable. So I don't subscribe to 'stringy ints' because all variables have a stringy element naturally. If I had any need for 'strict' constraints on a variable it has to cover both the size and type of the data, simply saying int is of little use if the data is too big anyway. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
