Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21885 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75929 invoked by uid 1010); 16 Feb 2006 17:55:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 75914 invoked from network); 16 Feb 2006 17:55:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Feb 2006 17:55:14 -0000 X-Host-Fingerprint: 128.32.61.106 smtp-out1.Berkeley.EDU Linux 2.5 (sometimes 2.4) (4) Received: from ([128.32.61.106:36216] helo=smtp-out1.berkeley.edu) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 73/81-61409-18CB4F34 for ; Thu, 16 Feb 2006 12:55:13 -0500 Received: from dhcp-139-92.ohr.berkeley.edu ([169.229.139.92] helo=peiscg33m) by calmail-fe4.berkeley.edu with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (auth login:saramg@berkeley.edu) (envelope-from ) id 1F9nLR-0007cG-Ei; Thu, 16 Feb 2006 09:55:09 -0800 Message-ID: <000901c63322$20b5d550$5c8be5a9@ohr.berkeley.edu> Reply-To: "Sara Golemon" To: "Zeev Suraski" Cc: , "Andi Gutmans" References: <002201c6331d$a79473b0$58d01a44@stumpy> <7.0.1.0.2.20060216192615.099c9598@zend.com> Date: Thu, 16 Feb 2006 09:55:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Subject: Re: Minor engine patch to facilitate PECL/operator From: saramg@berkeley.edu ("Sara Golemon") > >Enter PECL/operator, which tries to implement operator overloading > >for objects (and does a decent job at that). In the interrest of > >ease of use and consistency, every overloaded binary operator is > >[meant to be] left associative. This is, in the expression expr1 > >op expr2 expr1 gets to decide how it will combine-with/compare-to expr2. > > > What does it mean that it gets to decide? If it's left associative, > then it's evaluated from left to right, no? > Yes, and that's the problem. $a > $b *isn't* read by the current parser as $a > $b, it's read as $b < $a. For all normal PHP comparisons, the distinction is unimportant... 4 < 2 and 2 > 4 will both evaluate to false after all. However, the way object operator overloading is being done is: If the first operand is an object implementing an overload method for this op, dispatch to that method rather than using the tranditional comparison function. e.g. $a < $b turns into $a->__is_smaller($b). Now say you've got that expression the other way around: $a > $b. What you'd expect is that if $a is an object, it'll try to call $a->__is_greater($b). What you get is an automatic reversal of the expression by the engine: $b < $a, which turns into: "If $b is an object, dispatch to $b->__is_smaller($a);" which is not the same thing. -Sara