Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70072
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <527F3B9B.8040006@sugarcrm.com>
References: <CAGa2bXY4mS27qAfD6U03pxFyRNyK1AAowY3D0MxeqcjNQSKqRw@mail.gmail.com>
 <527DF228.1080108@sugarcrm.com> <CAGa2bXbqR7Cg_pmq0VnZhMHzXfTrR7ve1yYKoeiEf88Oght2tg@mail.gmail.com>
 <527F3B9B.8040006@sugarcrm.com>
Date: Sun, 10 Nov 2013 17:57:23 +0900
Message-ID: <CAGa2bXaAm_A3aqohJXKEF9czi=0Tcu-NPTe0rgP_WAR-7_BMDA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3436962e24c704eaced043
Subject: Re: [PHP-DEV] [RFC] Comparison and conversion inconsistency - need
 more info
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7b3436962e24c704eaced043
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Sun, Nov 10, 2013 at 4:54 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > 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?
>

http://us2.php.net/min

Our manual does not have NULL/BOOL type behavior explanations.


> > 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.


I agree your point fully.
I think almost all users are using min() only with integer/float and not
with bool/null.

The bug report might be confusing, but it's is not complaining -1 != false
or like, but it's complaining min() is not following standard PHP
comparison rules.

-----------------------------------
if (-1 < NULL)
  echo 'NULL is smaller';
else
  echo '-1 is smaller';
-----------------------------------
returns '-1 is smaller' as all of us expects.

However,
-----------------------------------
min(-1,null)
-----------------------------------
returns NULL.

NULL is evaluated as 0 in scalar contexts, but not with min(). NULL wins
negative values because of the compare_function() in zend_operators.c.
compare_function() treats NULL/BOOL type special way. (i.e Not like
expression in 'if' statement or like)

That's the reason why I was surprised.

I think feasible solution for min() misbehavior is to use new function that
uses standard PHP comparison rule. I'll check PHP functions that uses
compare_function() later. There may be other array functions use it. I'm
not sure if there are 'internal' functions that does not perform
comparison(or conversion) non standard way like compare_function().

It's a small change, but it might have big impact for some users.
Therefore, if I'll propose this RFC as PHP 6 matter.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--047d7b3436962e24c704eaced043--