Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49845
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <01f9082a02170415e626b2d65d090460.squirrel@www.l-i-e.com>
In-Reply-To: <AANLkTim4SiDp1mDZtPBX0Ejt-+BGRLS=+_6+8WzfPaTE@mail.gmail.com>
References: <AANLkTim4SiDp1mDZtPBX0Ejt-+BGRLS=+_6+8WzfPaTE@mail.gmail.com>
Date: Sun, 3 Oct 2010 06:47:24 -0500
To: internals@lists.php.net
User-Agent: SquirrelMail/1.4.21 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] Expose compare_function() to userspace
From: ceo@l-i-e.com ("Richard Lynch")

On Thu, September 30, 2010 9:44 am, Adam Harvey wrote:
> Unrelated to the Comparable RFC, are there any objections to adding a
> function that simply wraps compare_function()? It's depressingly
> common to end up writing a construct like the following in comparison
> callbacks, so I think we might as well encapsulate the pattern in an
> actual function:
>
> if ($a < $b) {
>   return -1;
> }
> elseif ($a > $b) {
>   return 1;
> }
> return 0;
>
> If I don't hear kicking and screaming in the next few days, I'll slip
> this into trunk. I can provide a patch/RFC in advance if there's
> demand, but it'll be about as simple as you imagine. :)
>
> The one thing that I would like bikeshedding^Wfeedback on is the name:
> cmp() makes the most sense to me, since it lines up well with Python
> and (to a lesser extent) Perl, but if there are concerns about
> potential name clashes with existing code, may I suggest
> var_compare(). Get your votes and/or suggestions in!

I don't really think we need this in core.

I mean, yeah, I may have written the same function a few times, but
it's not exactly brain surgery. (which I've been through so I know :-)

Except for handling non-int input, which you probably won't do in the
core function anyway...

Seems kind of a pointless bloat to this developer.

-1

PS
It should be INT_cmp if it takes INT.  Or num_cmp or number_cmp

var_cmp et al would imply any sort of var...

Though I guess using < and > means it would do whatever those
operators do for Objects, strings, or resources...  Which I wouldn't
even want to try to predict and rely on anyway.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE