On 21 February 2015 at 23:13, Lester Caine <les...@lsces.co.uk> wrote: > On 21/02/15 19:56, Pádraic Brady wrote: >> 1. Happy to see leading/trailing spaces excluded. > 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?
They also may not be a data source. Big Universe. Many possibilities. Bear in mind that one of the assumptions of the strict camp is programmers will make errors. Taking a known field from a database, and throwing it a known parameter, and doing so by design? Not an error. C may do it a certain way, but I can't really take that as anything more than C having its own preference which doesn't tell whether in absolute terms whether it's correct or not. YMMV. >> 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. Mentioned to clarify. The RFC has a table of various coercion rules. I like my tables complete. >> 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? Or perhaps have a typehint for a string which definitely must be interpreted as an integer/float. The stringyint! Fine: numeric? I'm not sure if that was ever a well supported thing, but it would be nice to clarify if it's a runner and, if so, not to jump the gun by making int/float overly permissive. You may yet have your cake. Zeev, any chance? No chance? >> 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. See above >> 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. Again, merely a clarification for my accurate tables fetish. >> 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! We should definitely put that in a major PHP version then. Seriously, that was off the cuff and intentionally conservative. It would need way more discussion. >> 7. In string to float, only capital E or also small e? > lower case e is common ... Yes, and not mentioned in the RFC table... So it bugged me. >> 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 My term is glorious in its perfection. Disagreement will not be permitted! > 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 :( A string is always a string. Until someone decides it represents an integer. At the heart of our current RFC faceoff, is that some people expect that throwing a string at an int expecting parameter should transform the string to an int automatically. Other people reason that since we cannot inspect the string personally, the automatic assumption might be erroneous. Perhaps the string really was just a string. It was never intended to be an integer. Yes, if you throw a string at an int deliberately, then your vision is correct. The assumption others make is that programmers are not perfect, and may do the same thing entirely in error. In those cases, a silent permissive coercion equates to an error going undetected. Thereafter we can have some fun debating whether the receiving parameter should be typed to the expected input (string) or the expected final input (integer). On the balance of not annoying upstream users, many would find it attractive to do one thing on the public API and the other internally where control of parameter flows is more absolute. Back on the topic of your cake, it may be possible to resolve that dilemna with a different type specific to that purpose. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
