Re: [RFC] Comparison and conversion inconsistency - need more info

Hi! > For example, string may be converted to int when it seems int/float or hex, > but it's not converted when it seems octal or binary. I think it's not > documented yet. (At least not clearly, is it? Adding octal/binary conversion > is not a good idea. Likewise, -1 should be true.) 0x conversion is kind of documented in http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion by referring to strtod. But I agree that it might as well spell it out there without sending people to manpages. As for the rest, I'm not sure what we can document there besides the fact numbers are decimal, which is kind of obvious. This is certainly not "inconsistent behavior" - this is a behavior which is consistent and documented, just it refers to other place, which can be improved. > I'm wandering whether there are functions like min(). It does not I would assume anything that does standard comparisons would be working the same. Doing otherwise would be, yes, inconsistent. So any function calling compare_function would do the same thing min() does, I imagine. > follow basic comparison/conversion rules. min() behavior is nonsense and In which case does min() not follow comparison rules as outlined in the manual? > it would be good fixing min() at some point. Not many users will be > affected, IMO. I think this opinion is wrong, and I don't see why these rules are "nonsense". Some of these rules may not produce result you have expected, but only because you are comparing types between which natural comparison does not exist, so we have to choose some behavior which is arbitrary to a measure. If you look at Python, for example, "None < -1" is true (or, if you will, True). In Javascript, however, "null < -1" is false. Both choices have reasons. Changing basic comparison rules in the language has very high potential of affecting users, since virtually every script does comparisons. Of course, you don't know if anybody ever compares to nulls, but that's not impossible, so we need to be very careful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227