Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70070
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender)
Message-ID: <527F3B9B.8040006@sugarcrm.com>
Date: Sat, 09 Nov 2013 23:54:03 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXY4mS27qAfD6U03pxFyRNyK1AAowY3D0MxeqcjNQSKqRw@mail.gmail.com> <527DF228.1080108@sugarcrm.com> <CAGa2bXbqR7Cg_pmq0VnZhMHzXfTrR7ve1yYKoeiEf88Oght2tg@mail.gmail.com>
In-Reply-To: <CAGa2bXbqR7Cg_pmq0VnZhMHzXfTrR7ve1yYKoeiEf88Oght2tg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Comparison and conversion inconsistency - need
 more info
From: smalyshev@sugarcrm.com (Stas Malyshev)

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