Hi Lukas, On Mon, Jul 6, 2009 at 11:03 PM, Lukas Kahwe Smith<m...@pooteeweet.org> wrote: > Ok, I have updated the RFC now with a table that shows that I expect to pass > and fail. Its fairly late, so I might have missed something. In general what > I am proposing is more lax than is_*() for the most part. Especially when it > comes to checking strings.
I hope you have missed some things (or that they are typos) because otherwise a good chunk of this is plain lunacy. value string float int numeric scalar bool array 0 (integer) fail fail pass pass pass pass fail 1 (integer) fail pass pass pass pass pass fail 0 fails conversion to a float, but 1 and 12 succeed? 12 (double) fail pass pass pass pass fail fail It may seem that this is a good idea (12.0 passing the int check), but what if 12.0 is OK, but 144.0/12 does not (which might not be 12.0 due to floating point error)? '0' (string) pass fail fail pass pass pass fail '1' (string) pass fail fail pass pass pass fail '12' (string) pass pass pass pass pass fail fail Absolute lunacy. Please let this be a typo. '12.0' (string) pass pass pass pass pass fail fail '12.34' (string) pass pass fail pass pass fail fail As above. I think you need to present this information better. One advantage of Ilia's proposal is that it is very clear. It does two things: strong type check, or the same casts that currently exist. I think you need to say what changes you are introducing, and why they are introduced. The same flaw existed with my proposal: I dont think anyone wants a 3rd set of rules. > I do not understand why its suddenly so urgent to get this feature in(*), > that people already speak about frustration over the process after just a I think because this same issue has been going on for so long, and seem to be so very close now. This idea has been punted around in various forms and patches for years at this stage. > few days. We dont need years and usually not months, but this is not the > addition of some function. Its an extension to the language syntax, so I > think its totally normal that we talk about this for at least a month. Well yes. But with near consensus, there is a danger of a 90% good-enough patch being derailed by new proposals, and I get the impression most people would be happier with the 90% patch. > shouldn't we > rather talk about finding a better release process (maybe build on top of > recent developments in the version control world) that enables us to more > quickly get x.y releases out without preventing bigger features like unicode > from ever maturing? I've heard you mention this before. Please roll it into an RFC so we can think about it (FWIW, the idea that newer version control systems will somehow change everything makes little sense, so I think a lot of detail is required here). Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
