# RFC: Comparable interface - Thread: https://externals.io/message/49807 - Original archive: https://news-web.php.net/php.internals/49807 - Started by Adam Harvey on 2010-09-30T13:33:05+00:00 - Messages: 29 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/49807.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49807 — Adam Harvey — 2010-09-30T13:33:05+00:00 URL: https://externals.io/message/49807#49807 All, I've just written an RFC (with a patch against trunk) to implement a Comparable interface similar to that in Java — in effect, allowing object instances to be compared with semantics defined in userspace. This is admittedly at the lower end of RFC-worthy proposals, but it's a good system, and I'd like to see it used a little more. Plus, it's good practice for the more interesting stuff to come. :) The RFC is at http://wiki.php.net/rfc/comparable, and the patch at http://www.adamharvey.name/patches/comparable.diff.txt. Any and all feedback welcome, particularly since I'm still learning my way around the innards of the Zend Engine, and it's entirely possible (indeed, likely) that I've overlooked something obvious. If there's no great resistance to the concept or implementation, I'm happy enough to flip this into the voting stage sooner rather than later so we can get it out of the way. Thanks, Adam --- ## #49809 — Kalle Sommer Nielsen — 2010-09-30T14:08:28+00:00 URL: https://externals.io/message/49807#49809 · In reply to: #49807 Hi Adam 2010/9/30 Adam Harvey : > All, > > I've just written an RFC (with a patch against trunk) to implement a > Comparable interface similar to that in Java — in effect, allowing > object instances to be compared with semantics defined in userspace. > This is admittedly at the lower end of RFC-worthy proposals, but it's > a good system, and I'd like to see it used a little more. Plus, it's > good practice for the more interesting stuff to come. :) > > The RFC is at http://wiki.php.net/rfc/comparable, and the patch at > http://www.adamharvey.name/patches/comparable.diff.txt. Any and all > feedback welcome, particularly since I'm still learning my way around > the innards of the Zend Engine, and it's entirely possible (indeed, > likely) that I've overlooked something obvious. I think its a great addition, but I think the interface should be defined within ZE like the other base interfaces that interact directly with the language syntax (like Iterator) and not in SPL. The patch itself is flowlessly simple and I think it would be a great addition for trunk, +1 -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #49811 — johannes@schlueters.de — 2010-09-30T14:24:01+00:00 URL: https://externals.io/message/49807#49811 · In reply to: #49807 > All, > > I've just written an RFC (with a patch against trunk) to implement a > Comparable interface similar to that in Java — in effect, allowing > object instances to be compared with semantics defined in userspace. > This is admittedly at the lower end of RFC-worthy proposals, but it's > a good system, and I'd like to see it used a little more. Plus, it's > good practice for the more interesting stuff to come. :) What is this "more interesting stuff to come"? - currently it is a bit syntactic sugar, one might argue a feature which makes reading code harder(*), and we are careful with adding such. (*) Right now it is quite clear what happens if you read $a == $b there are a few edge cases (0 == "100000 mails ina thread") but overall quite clear. With your patch "anything" might happen, which is hard to detect as we don't enforce strong typing, which would give a hint. johannes --- ## #49812 — johannes@schlueters.de — 2010-09-30T14:26:17+00:00 URL: https://externals.io/message/49807#49812 · In reply to: #49809 > I think its a great addition, but I think the interface should be > defined within ZE like the other base interfaces that interact > directly with the language syntax (like Iterator) and not in SPL. s/should/has to/ The engine shall not depend on anthing in PHP. In theory you should be able to do cd Zend && ./buildconf && ./configure && make to built a PHP-less engine (needs TSRM somewhere though). (Please mind my othe mail in this thread, too) johannes --- ## #49813 — Gustavo Lopes — 2010-09-30T14:36:20+00:00 URL: https://externals.io/message/49807#49813 · In reply to: #49812 On Thu, 30 Sep 2010 15:26:17 +0100, Johannes Schlüter wrote: > > > […] > > s/should/has to/ > > The engine shall not depend on anthing in PHP. In theory you should be > able to do cd Zend && ./buildconf && ./configure && make to built a > PHP-less engine (needs TSRM somewhere though). > Right. Saying this is the way the Countable interface is implemented like is said in the RFC is not really a valid argument, since the engine knows nothing about that interface, only the "count" function (which is in the standard extension) does. -- Gustavo Lopes --- ## #49816 — Derick Rethans — 2010-09-30T14:47:30+00:00 URL: https://externals.io/message/49807#49816 · In reply to: #49811 > > > […] > > What is this "more interesting stuff to come"? - currently it is a bit > syntactic sugar, one might argue a feature which makes reading code > harder(*), and we are careful with adding such. > > > (*) Right now it is quite clear what happens if you read > $a == $b > there are a few edge cases (0 == "100000 mails ina thread") but overall > quite clear. With your patch "anything" might happen, which is hard to > detect as we don't enforce strong typing, which would give a hint. It sounds a little bit like operator over loading to me... cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #49817 — Adam Harvey — 2010-09-30T14:50:56+00:00 URL: https://externals.io/message/49807#49817 · In reply to: #49812 2010/9/30 Johannes Schlüter : > > > […] > > s/should/has to/ > > The engine shall not depend on anthing in PHP. In theory you should be > able to do cd Zend && ./buildconf && ./configure && make to built a > PHP-less engine (needs TSRM somewhere though). Fair enough. I'll cook up a revised patch tomorrow that removes the SPL dependency and moves the interface definition into Zend. Adam --- ## #49818 — Adam Harvey — 2010-09-30T14:57:41+00:00 URL: https://externals.io/message/49807#49818 · In reply to: #49816 (Omnibus reply, since Johannes's original e-mail hasn't yet dropped into my ever-so-flaky mail setup. I have read it in full on news.php.net, though.) > > > […] Nothing that's likely to be ready before the forthcoming release cycle. I really did just want the RFC writing practice, since I haven't done one within PHP's structure before. :) > > […] Sure, but I think by that argument interfaces like Countable, Traversable and ArrayAccess would be out too. It is syntactic sugar, but I think it's useful syntactic sugar. One of the examples I toyed with tossing into the RFC was a date class, but I figured the argument against that is the obvious one of "people would use DateTime anyway". I think there are a range of potential uses here. 2010/9/30 Derick Rethans : > It sounds a little bit like operator over loading to me... I guess it is in a sense, since the comparison operators are by definition operators. I don't really see this is as starting any sort of slippery slope towards a full operator overloading implementation, though -- it's limited in scope, and really seems like a small, logical feature to make objects a little bit more useful to me. Adam --- ## #49820 — Gustavo Lopes — 2010-09-30T15:13:40+00:00 URL: https://externals.io/message/49807#49820 · In reply to: #49807 > I've just written an RFC (with a patch against trunk) to implement a > Comparable interface similar to that in Java — in effect, allowing > object instances to be compared with semantics defined in userspace. > This is admittedly at the lower end of RFC-worthy proposals, but it's > a good system, and I'd like to see it used a little more. Plus, it's > good practice for the more interesting stuff to come. :) > > The RFC is at http://wiki.php.net/rfc/comparable, and the patch at > http://www.adamharvey.name/patches/comparable.diff.txt. Any and all > feedback welcome, particularly since I'm still learning my way around > the innards of the Zend Engine, and it's entirely possible (indeed, > likely) that I've overlooked something obvious. > > If there's no great resistance to the concept or implementation, I'm > happy enough to flip this into the voting stage sooner rather than > later so we can get it out of the way. > I think this would be a good idea if limited to provide a userspace alternative to compare_objects, like Countable provides a userspace alternative to count_elements. That is, you would only modify zend_std_compare_objects (not compare_function!) and add there the additional logic where you'd check if the objects had the same class (or perhaps one was of a subclass of the other, in which case you'd use the compare method of the subclass) and call the compare method. Allowing comparison of objects with non-objects can become very confusing: * What if the objects are not of the same class? What if one is of a subclass of the other? Is equality not symmetric? * How do you interact with 'get' and 'cast_object'/'__tostring'? It's true that there's already overloading of '==' for internal classes, but it's very predictable: both operands must have the same 'compare_objects', otherwise it's not used. For the record, the current rules are relatively simple: * If both are objects and have the same 'compare_objects' handler, use it. * If the first operand is an object and has a 'get' (tried first) or 'cast_object' handler call it, and repeat with the new value. * Try the same for the second operand. -- Gustavo Lopes --- ## #49821 — Adam Harvey — 2010-09-30T15:25:28+00:00 URL: https://externals.io/message/49807#49821 · In reply to: #49820 > That is, you would only modify zend_std_compare_objects (not > compare_function!) and add there the additional logic where you'd check if > the objects had the same class (or perhaps one was of a subclass of the > other, in which case you'd use the compare method of the subclass) and call > the compare method. > > Allowing comparison of objects with non-objects can become very confusing: > > * What if the objects are not of the same class? What if one is of a > subclass of the other? Is equality not symmetric? > * How do you interact with 'get' and 'cast_object'/'__tostring'? The initial version of the patch actually did just that: it simply modified zend_std_compare_objects. That's pretty much the cleanest way you could do it. :) I dropped it and went with the more complicated approach involving changing compare_function because I actually think allowing comparison with non-objects is a valuable feature. Objects may be more strongly typed in PHP than scalars, but there's still a certain amount of juggling that can take place via __toString(), so I think it would be out of place to require an object on both sides. Additionally, there are already semantics built into compare_function to handle object/non-object comparisons, although they're of very limited use in practice. The specific use case I had in mind was allowing comparisons of objects representing monetary amounts against numeric values (since that was a particular itch I had a couple of years ago), but I'm sure there would be others. In terms of the specific question as to whether equality is symmetric: certainly it should be, but we would have no way of enforcing it, obviously. Java doesn't either, though: there's simply a note in the documentation saying that implementations should be symmetric. Adam --- ## #49823 — Gustavo Lopes — 2010-09-30T15:54:15+00:00 URL: https://externals.io/message/49807#49823 · In reply to: #49821 > The initial version of the patch actually did just that: it simply > modified zend_std_compare_objects. That's pretty much the cleanest way > you could do it. :) > > (...) Additionally, there > are already semantics built into compare_function to handle > object/non-object comparisons, although they're of very limited use in > practice. > > The specific use case I had in mind was allowing comparisons of > objects representing monetary amounts against numeric values (since > that was a particular itch I had a couple of years ago), but I'm sure > there would be others. > It's true that the engine already allows comparison of objects with scalars, but that can only happen after a cast. At least you now have the guarantee that if you compare a scalar x of type u with an object y and they're equal, then x === (u) y is also true*. With your patch, you could make $obj == "jjj" be true and (string) $obj yield a completely different thing. Obviously you wouldn't do this on purpose, my point is that this could lead to a hard to debug problem. This is what makes me very reluctant to support this more general approach of allowing scalar-object comparisons. * (maybe there's some edge case where this wouldn't happen because the engine is inconsistent with its preferences towards get, cast_object and __toString, but my point stands) > In terms of the specific question as to whether equality is symmetric: > certainly it should be, but we would have no way of enforcing it, > obviously. Java doesn't either, though: there's simply a note in the > documentation saying that implementations should be symmetric. Obviously it must be the programmer's responsibility to write a compare() function that is symmetric (and in general, establish a total order). My point about about symmetry was another: you know have potentially different code running in these two cases: $a == $b $b == $a The current implementation is "symmetric" in the sense the compare_objects handler is called only if both objects have the same handler (only the arguments are exchanged). -- Gustavo Lopes --- ## #49829 — Stas Malyshev — 2010-09-30T20:28:49+00:00 URL: https://externals.io/message/49807#49829 · In reply to: #49807 Hi! > The RFC is at http://wiki.php.net/rfc/comparable, and the patch at > http://www.adamharvey.name/patches/comparable.diff.txt. Any and all > feedback welcome, particularly since I'm still learning my way around > the innards of the Zend Engine, and it's entirely possible (indeed, > likely) that I've overlooked something obvious. It is not clear from the RFC, if the engine encounters $a <= $b, what actually happens? E.g.: 1. Is only $a checked for Comparable or also $b? 2. How it is ensured that if $a < $b then $b > $a? 3. Would sorting work with it? 4. If both $a and $b are objects with different compare functions, how it is determined whose function is used? Note that operators like == are assumed to be commutative, and less/more operators are assumed to be commutative in pairs, like above. As a side note, if we have traits we might instead think of having Comparable trait or interface or both, which would declare having compareTo() standard feature (as Java does) without messing with the engine and overloading operators. Surely, it would be more verbose, but that might be a good thing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49834 — Adam Harvey — 2010-10-01T02:57:18+00:00 URL: https://externals.io/message/49807#49834 · In reply to: #49829 For what it's worth, I'm planning to update the RFC later today with an updated SPL-less patch and the start of a Q&A section similar to what we've had in the other RFCs. I'll send an e-mail when it's ready. > It is not clear from the RFC, if the engine encounters $a <= $b, what > actually happens? > E.g.: > 1. Is only $a checked for Comparable or also $b? Both $a and $b are checked. > 2. How it is ensured that if $a < $b then $b > $a? That's up to the userspace developer to get right when they're implementing their compareTo method. I expect the manual would have a dire warning about the possible consequences of not making them equivalent. > 3. Would sorting work with it? Yes. > 4. If both $a and $b are objects with different compare functions, how it is > determined whose function is used? Note that operators like == are assumed > to be commutative, and less/more operators are assumed to be commutative in > pairs, like above. The left operand wins, so $a. > As a side note, if we have traits we might instead think of having > Comparable trait or interface or both, which would declare having > compareTo() standard feature (as Java does) without messing with the engine > and overloading operators. Surely, it would be more verbose, but that might > be a good thing. I don't think that gains us an awful lot (it's no different to simply having an interface or trait within a codebase requiring such a function, which has been common practice in some of the systems I work on anyway), but it'd be easy enough to add, obviously. Adam --- ## #49835 — Adam Harvey — 2010-10-01T08:38:19+00:00 URL: https://externals.io/message/49807#49835 · In reply to: #49807 > I've just written an RFC (with a patch against trunk) to implement a > Comparable interface similar to that in Java — in effect, allowing > object instances to be compared with semantics defined in userspace. > This is admittedly at the lower end of RFC-worthy proposals, but it's > a good system, and I'd like to see it used a little more. Plus, it's > good practice for the more interesting stuff to come. :) I've updated the RFC with a fresh patch that doesn't involve SPL at all and attempted to incorporate some of the questions and answers so far into the RFC. I've also added a section for concerns with the RFC; I've attempted to distil the concerns I've seen so far, but please feel free to edit that list if specific concerns are misrepresented or unrepresented. Links: RFC: http://wiki.php.net/rfc/comparable Patch v2: http://www.adamharvey.name/patches/comparable-v2.diff.txt Thanks, Adam --- ## #49836 — Gustavo Lopes — 2010-10-01T09:27:51+00:00 URL: https://externals.io/message/49807#49836 · In reply to: #49835 > > > […] > > I've updated the RFC with a fresh patch that doesn't involve SPL at > all and attempted to incorporate some of the questions and answers so > far into the RFC. I've also added a section for concerns with the RFC; > I've attempted to distil the concerns I've seen so far, but please > feel free to edit that list if specific concerns are misrepresented or > unrepresented. > > Links: > > RFC: http://wiki.php.net/rfc/comparable > Patch v2: http://www.adamharvey.name/patches/comparable-v2.diff.txt > Here's a new concern: I find a bad idea to call compareTo *before* 'compare_objects'. This means that if in your internal class you define your own comparison logic with 'compare_objects', you cannot make sure the userland subclasses won't completely replace your logic by implementing Comparable. So to prevent this you'd have to implement 'Comparable' yourself... The low level feature should have priority (look at e.g. Countable vs count_objects); you could always in your 'compare_objects' check for the interface and call it if you want to allow userspace subclasses to replace the comparison logic. The RFC says: > > […] > The tests for whether the operands implement Comparable occur before > any potential calls to get and cast_object. So basically this means that 'get' and 'cast_object' will never be called of an object $a will never be called if it's being compared to a Comparable object $b, right? This is not a very good idea because it puts the responsibility to deal correctly with proxy objects and scalar castable objects on the part of the implementor of the compareTo method. Tis means people implementing compareTo natively will almost never get it right. Let's say they want to make their object comparable with integers. You pass a proxy object that yields integers. Now the native implementor sees an object and must remember to check for the existence of 'get' and 'cast_object' and call them if necessary. Right. For userland implementations, the situation is not much better; the implementor for compare would (most likely) have to do an explicit cast to the type he wants to compare with and, of course, using stuff like 'gettype' would probably result in wrong behavior. TL;DR: 'get' and 'cast_object' should be checked for and, if necessary, called first. > > […] > The left operand wins, so $a. At least in Java, it's clear this is happening because you call a.compareTo(b). This is a dangerous feature... In my opinion, if they have different compareTo implementations, they shouldn't be compared. -- Gustavo Lopes --- ## #49837 — Pierre Joye — 2010-10-01T09:38:53+00:00 URL: https://externals.io/message/49807#49837 · In reply to: #49835 hi Adam, Thanks for writing and updating a RFC, always the best way to propose new features :) > > > […] > > I've updated the RFC with a fresh patch that doesn't involve SPL at > all and attempted to incorporate some of the questions and answers so > far into the RFC. I've also added a section for concerns with the RFC; > I've attempted to distil the concerns I've seen so far, but please > feel free to edit that list if specific concerns are misrepresented or > unrepresented. Maybe to get a context about how other languages work (or do not work) with these similar features, it could be interesting to look at the python (2.5) documentation: http://docs.python.org/release/2.5.2/ref/customization.html As I would be in favor of having a compareTo interface for similar objects, I worry a bit about comparing apple and pear. Yes, an apple can be greater than a pear in real world but the wtf is somehow huge in a php context. That's why I share Stas or Gustavo thoughts about comparing instances of different classes (or with inheritance from internal classes without a comparable implementation). To be more precised, by "wtf", I mean that $a == $b may not mean that $b == $a (as in python for example). That's something we should consider carefully. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49846 — Richard Lynch — 2010-10-03T11:53:53+00:00 URL: https://externals.io/message/49807#49846 · In reply to: #49807 > If there's no great resistance to the concept or implementation, I'm > happy enough to flip this into the voting stage sooner rather than > later so we can get it out of the way. If I'm understanding this correctly, you're going to make it WAY too easy for scripters to screw up == and === and create bugs that are impossible to track down... Please, no. -1 -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #49848 — johannes@schlueters.de — 2010-10-03T14:16:05+00:00 URL: https://externals.io/message/49807#49848 · In reply to: #49818 > > […] > > Nothing that's likely to be ready before the forthcoming release > cycle. I really did just want the RFC writing practice, since I > haven't done one within PHP's structure before. :) I take this answer as "There's no true benefit from this and I wrote this patch just to learn" That's similar to the reasoning I had when writing my operator overloading patch quite a few years ago, which *I* never proposed and never would have proposed :-) johannes --- ## #49849 — Gustavo Lopes — 2010-10-03T14:21:36+00:00 URL: https://externals.io/message/49807#49849 · In reply to: #49848 On Sun, 03 Oct 2010 15:16:05 +0100, Johannes Schlüter wrote: > > > […] > I actually see no reason why we shouldn't expose the compare overload we already have for internal classes to userspace classes. However, the patch goes much further than this and, even if that direction were desired, it takes, in my opinion, the wrong options in the details I've mentioned. -- Gustavo Lopes --- ## #49850 — johannes@schlueters.de — 2010-10-03T14:37:41+00:00 URL: https://externals.io/message/49807#49850 · In reply to: #49849 > On Sun, 03 Oct 2010 15:16:05 +0100, Johannes Schlüter > wrote: > > > […] > > I actually see no reason why we shouldn't expose the compare overload we > already have for internal classes to userspace classes. For internal classes it is needed, as they extend zend_object with custom information we don't find in hash tables etc. so without the internal handler we can't decide whether two objects are equal or not. > However, the patch goes much further than this and, even if that direction > were desired, it takes, in my opinion, the wrong options in the details > I've mentioned. For userspace-defined classes the equal and other comparison operation are clearly defined. (Well, maybe some of the conversions aren't always that clear, but still follow rules) When adding this feature the comparison operators change their meaning ... johannes --- ## #49851 — Gustavo Lopes — 2010-10-03T17:34:31+00:00 URL: https://externals.io/message/49807#49851 · In reply to: #49850 On Sun, 03 Oct 2010 15:37:41 +0100, Johannes Schlüter wrote: > > > […] > > For internal classes it is needed, as they extend zend_object with > custom information we don't find in hash tables etc. so without the > internal handler we can't decide whether two objects are equal or not. > > > […] > > For userspace-defined classes the equal and other comparison operation > are clearly defined. (Well, maybe some of the conversions aren't always > that clear, but still follow rules) > > When adding this feature the comparison operators change their > meaning ... You raise a fair point -- the motivation to override the comparison operator for internal classes is indeed bigger because the state is not in the usual places. However: * The functionality already exists; comparison operators already have their meaning "changed" (read: user-defined) for some objects. * I'd argue the current behavior (comparing classes and properties) is of limited use for equality. It's common to lazy-load the properties of the objects, which makes the current comparison behavior unreliable. * The current behavior for >, <, etc. is completely useless. It's unpredictable and it doesn't even establish a total order: $a = new stdclass; $a->prop = null; $b = new stdclass; $b->prop2 = null; var_dump($a > $b); //false var_dump($a == $b); //false var_dump($b > $a); //false -- Gustavo Lopes --- ## #49852 — Pierre Joye — 2010-10-03T18:02:13+00:00 URL: https://externals.io/message/49807#49852 · In reply to: #49851 hi Gustavo, > You raise a fair point -- the motivation to override the comparison operator > for internal classes is indeed bigger because the state is not in the usual > places. However: > > * The functionality already exists; comparison operators already have their > meaning "changed" (read: user-defined) for some objects. > * I'd argue the current behavior (comparing classes and properties) is of > limited use for equality. It's common to lazy-load the properties of the > objects, which makes the current comparison behavior unreliable. > * The current behavior for >, <, etc. is completely useless. It's > unpredictable and it doesn't even establish a total order: > > $a = new stdclass; > $a->prop = null; > $b = new stdclass; > $b->prop2 = null; > > var_dump($a > $b); //false > var_dump($a == $b); //false > var_dump($b > $a); //false It may be why Stas' proposal could fit better, a comparable interface. As there is then no confusion with undefined and useless behaviors with normal comparison ops. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49855 — Stas Malyshev — 2010-10-03T23:18:36+00:00 URL: https://externals.io/message/49807#49855 · In reply to: #49851 Hi! > * The current behavior for>,<, etc. is completely useless. It's > unpredictable and it doesn't even establish a total order: > > $a = new stdclass; > $a->prop = null; > $b = new stdclass; > $b->prop2 = null; > > var_dump($a> $b); //false > var_dump($a == $b); //false > var_dump($b> $a); //false That's because there's no total ordering of generic objects that can make sense. Only very specific objects - such as ones representing numeric qualities or having numeric properties - can be ordered, most of objects are unordered. And comparing objects with scalars automagically might bring a lot of surprises as nobody really expects $a == $b and $b == $a to be different now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49858 — Gustavo Lopes — 2010-10-03T23:32:19+00:00 URL: https://externals.io/message/49807#49858 · In reply to: #49855 On Mon, 04 Oct 2010 00:18:36 +0100, Stas Malyshev wrote: > > […] > > That's because there's no total ordering of generic objects that can > make sense. Only very specific objects - such as ones representing > numeric qualities or having numeric properties - can be ordered, most of > objects are unordered. And comparing objects with scalars automagically > might bring a lot of surprises as nobody really expects $a == $b and $b > == $a to be different now. I never defended comparison of objects against scalars (though this is already possible, in a limited sense). Perhaps I ought to have changed the subject. I'm just saying that the current comparisons for user classes is either very limited (==) or completely useless (<, >, >=, <=). Given that, we could implement a *limited* mechanism for overloading those operators in user-land. If limited to objects of the same class (or with one operand of a subclass of the other), this could actually make the comparison operators useful with little potential for damage. It would also not be unprecedented since it's already allowed for internal classes. -- Gustavo Lopes --- ## #49867 — Richard Lynch — 2010-10-05T03:31:14+00:00 URL: https://externals.io/message/49807#49867 · In reply to: #49851 > * The current behavior for >, <, etc. is completely useless. It's > unpredictable and it doesn't even establish a total order: > > $a = new stdclass; > $a->prop = null; > $b = new stdclass; > $b->prop2 = null; > > var_dump($a > $b); //false > var_dump($a == $b); //false > var_dump($b > $a); //false Errrr. Which one of these would you expect to be "true"?... They're sure not equal, right? And what would make $a or $b "greater" than the other? I mean, *WHY* would you expect one of those to be "true", if you do expect one of them to be "true"? I sure can't find any logical a priori ordering, total, partial, or otherwise. Last time I checked, there was no "rule" that any set/graph or other mathematical collection had to have a defined ordering, even partial. But it's been ages since I got my Honors Math degree, so maybe they changed the rule while I wasn't looking... :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- Next page: https://externals.io/message/49807.md?page=2