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.
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
-Sara
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
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
Anyway, I think this case has some other issues. How would you treat
2 < $obj. Wouldn't you want to call $obj->__is_greater(2)? Actually
my suggestion would be to not make it left associative but to require
a consistent design. If you have $obj1 < $obj2 then I don't think it
has to be defined which one gets called or whether __is_smaller or
__is_greater is called. If either of these are overloaded, it should
know how to deal with objects that can compare with it (possibly via
interface, etc..) and with objects that it can't compare to (possibly
always returning false, etc...).
So I suggest to create the following behavior:
$obj < 2 - Calls $obj->__is_smaller(2);
$obj > 2 - Calls $obj->__is_greater(2); (figures our that 2 isn't
overloaded so checks $obj)
$obj1 > $obj2 - Can call either depending on which one implements the
overloading.
In any case, if at all, I think the right thing would be to have an
IS_GREATER opcode and not an extended_value hack. But as I said, I
don't think operator overloading should be part of standard PHP so I
think making such changes does not make immediate sense.
We could possibly split that into two opcodes for PHP 6 mainly as a
"documentation" feature of the source code so less is lost during the compile.
Andi
At 09:55 AM 2/16/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
<DISCLAIMER> I am not a big fan of operator overloading because after years of C++ development I came to the conclusion that the syntactic sugar it provided was not worth the debugging hours lost due to hidden magic happening. It actually makes it hard to understand certain code when you're just reading it then explicitly calling the methods like in Java, something like obj.equals(2). </DISCLAIMER><MYDISCLAIMER> Believe it or not, I agree with you on the readability problems inherent in overloading. I'm not by any measure asking for a blessing or even a whiff of a consideration of putting this kind of functionality in the language. It's a decidedly non-PHP feature and one which can stay happily in extension land where it'll avoid creaping into mainstream projects, while still existing as a usable tool for those who want it.
Of course, like all good knives, it does have its uses...
</MYDISCLAIMER>
Anyway, I think this case has some other issues. How would you treat
2 < $obj. Wouldn't you want to call $obj->__is_greater(2)? Actually
my suggestion would be to not make it left associative but to require
a consistent design. If you have $obj1 < $obj2 then I don't think it
has to be defined which one gets called or whether __is_smaller or
__is_greater is called. If either of these are overloaded, it should
know how to deal with objects that can compare with it (possibly via
interface, etc..) and with objects that it can't compare to (possibly
always returning false, etc...).
So I suggest to create the following behavior:
$obj < 2 - Calls $obj->__is_smaller(2);
$obj > 2 - Calls $obj->__is_greater(2); (figures our that 2 isn't
overloaded so checks $obj)
$obj1 > $obj2 - Can call either depending on which one implements the
overloading.
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)
We could possibly split that into two opcodes for PHP 6 mainly as a
"documentation" feature of the source code so less is lost during the
compile.
That would certainly address PECL/operator's needs and only costs the engine
in the form of a slightly increased binary (which the extval hack does
anyway).
-Sara
At 02:39 PM 2/16/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].
True.
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)We could possibly split that into two opcodes for PHP 6 mainly as a
"documentation" feature of the source code so less is lost during the
compile.That would certainly address PECL/operator's needs and only costs the engine
in the form of a slightly increased binary (which the extval hack does
anyway).
Yeah, well let's see if we can find some other compelling reasons to
possible make the change for PHP 6. In the meantime, I think
providing the patch with your extension should be OK. A hack for a hack :)
Andi
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
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
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? ;)
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-toexpr2.
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
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).
That's one reason (one which lends credibility to the overloading kills
readability argument).
PS: Is it a coincidence that goto support & operator overloading have the
same author? ;)
They say idle hands are the devil's playthings....
My hands are very idle....
:-|
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
That's not true, Ruby for example has operator overloading, and has no
problems with different meanings of x>y and y<x (but i don't know a
core class that does that).
Also, PHP already breaks the transitivity rule for the equality
operator ($a == $b and $b == $c does not imply $a == $c), so there's
not much new evil if a user can, by loading an extension, break the
symmetry of the comparison operators, IMO.
Regards,
Stefan Walk
At 11:55 17/02/2006, Stefan Walk wrote:
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
That's not true, Ruby for example has operator overloading, and has no
problems with different meanings of x>y and y<x (but i don't know a
core class that does that).
I mean real languages :) Seriously though, it sounds like a bad
idea to allow it.
Also, PHP already breaks the transitivity rule for the equality
operator ($a == $b and $b == $c does not imply $a == $c), so there's
not much new evil if a user can, by loading an extension, break the
symmetry of the comparison operators, IMO.
Oh I disagree. While we do have some unique cases in which
transitivity is not maintained, they are quite, well, unique, and
arguably make sense.
More importantly, the discussion here is not about transitivity
(although it does have transitivity implications). It's more
fundamental, it's about the very meaning of smaller-than /
greater-than and the relationship between them.
Zeev
Hello Zeev,
Friday, February 17, 2006, 12:09:26 PM, you wrote:
At 11:55 17/02/2006, Stefan Walk wrote:
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
That's not true, Ruby for example has operator overloading, and has no
problems with different meanings of x>y and y<x (but i don't know a
core class that does that).
I mean real languages :) Seriously though, it sounds like a bad
idea to allow it.
Also, PHP already breaks the transitivity rule for the equality
operator ($a == $b and $b == $c does not imply $a == $c), so there's
not much new evil if a user can, by loading an extension, break the
symmetry of the comparison operators, IMO.
Oh I disagree. While we do have some unique cases in which
transitivity is not maintained, they are quite, well, unique, and
arguably make sense.
More importantly, the discussion here is not about transitivity
(although it does have transitivity implications). It's more
fundamental, it's about the very meaning of smaller-than /
greater-than and the relationship between them.
Actually Sara only asked whether she could add a flag to some handlers.
That has nothing to with anything you started to discuss from there.
Best regards,
Marcus
At 01:24 18/02/2006, Marcus Boerger wrote:
Actually Sara only asked whether she could add a flag to some handlers.
That has nothing to with anything you started to discuss from there.
Uhm, Sara asked whether she could add a flag to a specific operator
to facilitate a certain behavior, namely, the ability to make x<y and
y>x be treated differently. It has everything to do with what I
discussed from there (but not with transitivity).
Zeev
Hello Zeev and hello Sara
Saturday, February 18, 2006, 1:04:20 AM, you wrote:
At 01:24 18/02/2006, Marcus Boerger wrote:
Actually Sara only asked whether she could add a flag to some handlers.
That has nothing to with anything you started to discuss from there.
Uhm, Sara asked whether she could add a flag to a specific operator
to facilitate a certain behavior, namely, the ability to make x<y and y>>x be treated differently. It has everything to do with what I
discussed from there (but not with transitivity).
the point is not being able to treat them differently. The point is being
able to distinguish them so the right operation is called. Btw, in c++ it
is common to do things like:
bool operator != (_IN Type& oth)
{
return !(operator == (oth));
}
for < and > it means in php the user could (should we add overloading) do
function __less_then($other)
{
return $other->__greater($this);
}
But before you think i want op overloading in php let me assure you that i
do not want that. The reson is that it is the opposite of our beloved KISS
approach. So for example sooner or later we'd reach a point where crazy
stuff - really crazy stuff - nobody understands is needed. For example
another view on C++. Most overloaders do checking for "has some value" or
"is valid" by:
operator bool () const {... }
Which leads to a lot of problems. While the correct version would be:
typedef MemberType ClassType::*unspecified_boolean_type;
operator ClassType::*unspecified_boolean_type()
{
return valid ? &ClassType::member : 0;
}
MemberType member;
And now tell me how many ppl do you know who understand the above and the
implications the simple bool conversion has.
Best regards,
Marcus
At 03:02 18/02/2006, Marcus Boerger wrote:
the point is not being able to treat them differently. The point is being
able to distinguish them so the right operation is called.
Erm sorry, but it's exactly the same :)
Zeev