At 19:23 16/02/2006, Sara Golemon wrote:
Hi, purely selfish request here, I'd like to make a minor change to
the parser... Just a bitty one... You won't even feel it...
Currently, when the parser encounters: expr1 > expr2 it quietly
(and reasonably) switches it around to expr2 < expr1 so that is can
reuse the ZEND_IS_SMALLER op. The executor has no idea this has
occured, but heck, why does it need to know after all?
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?
Since greater-than (and greater-than-or-equal-to) are quietly
flipped, PECL/operator has no way to tell the difference between the
two and has to assume op1 < op2 (when in fact op2 > op1 may be the
correct view). To solve this I've bundled a patch with
PECL/operator to set the otherwise unused extended_value to a 0/1
value depending on whether it's genuinely less-than or greater-than.
There are sleaker ways to do this than what's included in the patch
(e.g. a new zend_do_() method really isn't needed), but I was
attempting to touch as little as possible in implementing it.
Is there a chance of this getting merged into the engine? Or is
that just entirely too imposing for such an edge case extension.
http://cvs.php.net/viewcvs.cgi/pecl/operator/compare-greater-5.1.2.diff?view=markup&rev=1.2
The patch looks harmless enough but I'm not clear on why it's needed,
which makes me worry whether there's some 'magic' involved
here... Can you try to elaborate on what would be going wrong w/o it?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
