Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21894
Return-Path: <zeev@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 79459 invoked by uid 1010); 17 Feb 2006 03:22:03 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 79437 invoked from network); 17 Feb 2006 03:22:03 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 17 Feb 2006 03:22:03 -0000
X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4)
Received: from ([80.74.107.235:17424] helo=mail.zend.com)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id F2/D0-00612-E4B35F34 for <internals@lists.php.net>; Thu, 16 Feb 2006 21:56:15 -0500
Received: (qmail 23877 invoked from network); 17 Feb 2006 02:56:10 -0000
Received: from localhost (HELO zeev-notebook.zend.com) (127.0.0.1)
	by localhost with SMTP; 17 Feb 2006 02:56:10 -0000
Message-ID: <7.0.1.0.2.20060217045102.0b12e150@zend.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 17 Feb 2006 04:56:09 +0200
To: "Sara Golemon" <pollita@php.net>
Cc: "Andi Gutmans" <andi@zend.com>,<internals@lists.php.net>
In-Reply-To: <008301c63349$cfa9f8d0$5c8be5a9@ohr.berkeley.edu>
References: <002201c6331d$a79473b0$58d01a44@stumpy>
	<7.0.1.0.2.20060216192615.099c9598@zend.com>
	<000901c63322$20b5d550$5c8be5a9@ohr.berkeley.edu>
	<7.0.1.0.2.20060216134358.05a08240@zend.com>
	<008301c63349$cfa9f8d0$5c8be5a9@ohr.berkeley.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: Minor engine patch to facilitate PECL/operator
From: zeev@zend.com (Zeev Suraski)

At 00:39 17/02/2006, Sara Golemon wrote:
>I gave this some thought as I was designing the overloading approach. I
>didn't go there because I actually wanted to allow asymmetry between the
>operands as sometimes communative properties don't apply cleanly.  Most
>obviously in the case of sub/div ops, but also in certain other (less
>likely) spots like matrix maths. a[1,3] * b[3,1] is certainly different than
>b[3,1] * a[1,3].
>
>I'll take a look at applying this to the is_smaller op at least.  I'm not a
>master mathematician, but I'm fairly certain that 2 is always greater than
>1.(Cue the cue the internals@ response to the contrary)

I agree with that 'theory', I tend to think that relation operators 
fall in a different category from operation operators (or whatever 
they're called :)

x>y is pretty much by definition the same as y<x, so I don't think we 
need to allow for different implementations.  I think you need to 
reconsider allowing two different object types to be compared (hence 
opening the possibility for inconsistent results, e.g. both x>y and 
x<y evaluating to true).

The rest of the operators should be compatible with non-commutative 
implementations.

Zeev