RFC: Comparable interface View as Markdown

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

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.

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

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

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

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

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:

How do you interact with 'get' and 'cast_object'/'__tostring'?

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.

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.

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

hi Adam,

Thanks for writing and updating a RFC, always the best way to propose
new features :)

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.

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