Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73487 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62055 invoked from network); 31 Mar 2014 10:55:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Mar 2014 10:55:06 -0000 Authentication-Results: pb1.pair.com header.from=cryptocompress@googlemail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cryptocompress@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.43 as permitted sender) X-PHP-List-Original-Sender: cryptocompress@googlemail.com X-Host-Fingerprint: 209.85.214.43 mail-bk0-f43.google.com Received: from [209.85.214.43] ([209.85.214.43:46126] helo=mail-bk0-f43.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FA/32-44499-98949335 for ; Mon, 31 Mar 2014 05:55:06 -0500 Received: by mail-bk0-f43.google.com with SMTP id v15so1149620bkz.2 for ; Mon, 31 Mar 2014 03:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=t8+VXO6a60uR2OokyHiF5H5Uw8/K9xAo97ZoOmOcm60=; b=upV/4sN8c5U+2vKs9LheTZMqzGPw4/1S/7JhrCPf6H+sR+SnV+RDad304RG2OhwcSs 32YWP1DH9mGaUZxrPyDjg/grBYTQw6kQQ5D6XivALmF20rYB9UHrGLIPn6yuXRZVLWn3 jPhIqCppwJEjrqDNSlGv3qC1V29Mq7QycEq1MON/cAPRrstIcWr83PHbBDLVLNdPvOiU TZnFDaT5lTFARlUzr/nUavMKM2OomnZELwfjXYisfPiFqU7tfQ96qETINlAJWHP8kiCJ 4zf5iT0+XiIOMdmmU+4lnamLovv4WnTBiyEcikBnYniifC1IKYqEVdbRxUT6ukLIygXh tkNw== X-Received: by 10.205.6.7 with SMTP id oi7mr284242bkb.62.1396263303220; Mon, 31 Mar 2014 03:55:03 -0700 (PDT) Received: from [192.168.1.115] (mnch-5d8769de.pool.mediaWays.net. [93.135.105.222]) by mx.google.com with ESMTPSA id em17sm13266966bkb.12.2014.03.31.03.55.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 03:55:01 -0700 (PDT) Message-ID: <5339497A.2040506@googlemail.com> Date: Mon, 31 Mar 2014 12:54:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikita Nefedov CC: PHP Developers Mailing List References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] usort callback should always return integer (not float) From: cryptocompress@googlemail.com (Crypto Compress) Am 31.03.2014 11:00, schrieb Nikita Nefedov: > Hi, > > I've just stumbled upon this limitation in sorting (compare) > callbacks. Is there any > reason why we can't handle floats in this case? > > I think it would be nice to be able to return float from the callback > because it's often happens that all it does is just `return > $a->someMethod() - $b->someMethod();` (where someMethod() returns > float) or `return $a["something"] - > $b["something"];` and to make it work I need to write additional if > statement. I think the reasoning could be complex behavior of doubles? > Especially comparing doubles. But will we see any double-related > pitfalls when all our code does with it is `return retval < 0 ? -1 : > retval > 0 ? 1 : 0;` (so essentially - compares them to zero)? > > > I made a PR [1] on github for 5.6 version. I think this change is > pretty small and could go into 5.6 not breaking our release process > rules? Though it WILL introduce some BC breaks for userland code that > uses floats. But this code was already broken when it was relying on > old behavior. > > [1] https://github.com/php/php-src/pull/638 > Hi, try this: 0 ? 'gt' : 'equal'); // result is *not* equal cryptocompress