> <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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
