> De : Lester Caine [mailto:les...@lsces.co.uk] > > Fixed length fields may well be a data source so having to strip them > before using them just seems a backward step. The basic C library simply > strips the white space so are we looking at using an alternative?
I guess you got it wrong : we'll ignore leading and trailing blanks, as well as leading 0s. We say we restrict because, where we accepted *every* trailing chars, we now only accept blanks. So fixed length fields will work as before. > > 2. Rules don't make mention of leading zeroes, e.g. 0003 > Again data may well be zero padded. This is more likely to be historic > material, but it's yet another extra processing step. If we have to > process data before then asking if it's a valid number what is the > advantage of this? However of cause the C library switches to octal mode > and needs pre processing of leading zero's anyway. Leading 0s are skipped. Same as PHP 5. > > 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. > > 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. > > 5. Is ".32" coerced to float or only "0.32"? Merely for clarification. > Omitting the leading zero is normal when doing hand keyed data entry. > .32 is a valid data entry ... Omitting perhaps 20% of characters speeds > data entry. No difference with PHP 5. > > 6. Boolean coercion from other types... Not entirely sure myself. > > Completely off the cuff: <=0: false, >0:true, floats and strings need > > not apply. > That would be a major BC break! I am personally more in favor of reintroducing it. Test patch will show BC breaks and confirm. > > 7. In string to float, only capital E or also small e? > lower case e is common ... Don't know. Check on php5. No change. > > 8. I'll never stop call them "stringy" ints. > For some funny reason we tend to prefer to view numbers on the screen as > strings ... having the original string with a value which can be used > for calculation is simply how I thought PHP worked. A variable is more > than just a 'value', we need it's name which is a string, and a viewable > string could be useful, along with other flags. I had assumed up until > now that PHP was using that model but it seems not :( It is *mostly* using that model. Unfortunately, history demands that $a[32] and $a["32"] behave in different ways. There are more cases but this one is the most common one. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
