Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 16 Feb 2006 16:11:08 -0700
In-reply-to: <7.0.1.0.2.20060217005156.0b12d660@zend.com>
To: internals@lists.php.net
Cc: Zeev Suraski <zeev@zend.com>, Sara Golemon <saramg@berkeley.edu>,
	Andi Gutmans <andi@zend.com>
Message-ID: <200602161611.09362.benjcarson@digitaljunkies.ca>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <002201c6331d$a79473b0$58d01a44@stumpy>
	<000901c63322$20b5d550$5c8be5a9@ohr.berkeley.edu>
	<7.0.1.0.2.20060217005156.0b12d660@zend.com>
User-Agent: KMail/1.9.1
Subject: Re: Minor engine patch to facilitate PECL/operator
From: benjcarson@digitaljunkies.ca (Benj Carson)

Just thought I'd chime in here with an example that seemed relevant:

cout << "foo" << "bar" << endl;

cin >> input;

Here, << and >> have nothing to do with bit-shifting and have different 
meanings.  So, maybe one can't assume that '<' and '>' always have to apply 
to the typical mathematical operations (e.g. $pacman < $ghost).


Benj Carson


PS: Is it a coincidence that goto support & operator overloading have the 
same author? ;)

On Thursday 16 February 2006 15:55, Zeev Suraski wrote:
> I understand.  Aren't you slightly worried about the implications of
> making it possible for x>y to have a different meaning than y<x?
>
> In languages where operator overloading is supported, it comes hand
> in hand with strict typing, which wouldn't allow for different values
> for x>y and y<x...
>
> Zeev
>
> At 19:55 16/02/2006, Sara Golemon wrote:
> > > >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