« Return to Thread: operator overloading

Re: operator overloading

by Barzilai Spinak-2 :: Rate this Message:

Warner Onstine wrote:
> On 10/1/07, Barzilai Spinak <barcho@...> wrote:
>
>> Some points to consider:
>> 1) In order to use the <, <=, >, >= operators, the operands (or at least
>> the left operand) must implement Comparable
>>
>
> Which seems an unfortunate choice from my perspective.
>
So far, this looks like reasonable to me, since they are comparatos and
follow a standard Java pattern, and historical libraries even before
Java (the less-equal-greater than zero comparison makes some algorithms
more efficient)
>> 4) Normally in Groovy the == and != operator will call the equals method
>> of the left operand, passing the right operand.
>> * BUT* if the objects implement Comparable (as yours will do), then
>> it calls the compareTo method as explained
>>
>
> That seems like an even worse problem (especially in my situation right now)
>
In this case I partially agree with you... maybe == should always call
equals... but there are probably reasons why this is more convenient.
In any case... this is how it is implemented and I don't think it's
gonna change :-)

>> One last question, when you say (a <= b), do you want to DECLARE a
>> relation or TEST for its truth?
>>
>
> Test for its truth. if a is a subset of b (ie - all of a's elements
> are in b, and/or a equals b). This leads me right into my main issue
> here. If I do a comparison of two sets a and b.
> a = [1,2,3] (assume this is my custom class)
> b = [1,2,3,4,5,6]
>
> and I do
> a <= b this should return true, but if I now have
> c = [1,8]
> c <= b this should be false (because not all elements of c are in b)
> but I don't know what I should be returning from compareTo in this
> instance, it isn't less, it isn't equals, it isn't greater than, it's
> just false. So, it is beginning to look more and more like I can't do
> what I want to do with operator overloading here.
>
> Someone please correct me if I'm wrong.
>
> -warner
>

Now.. you may be willing to do two things
1) First you should be consistent with your semantics.
In your example c <= b should be false. Your semantics mean that c IS
NOT included in b. So any considerations about "greater than" are
irrelevant.
You check for "included or equals" and if both fail, then it is NOT
included-or-equals. Now, what do you return? How do you know what was
the operator that triggered the call? This takes us to the second point
2) If you are willing to restrict yourself to only using: ==, !=, <=,
< (i.e., don't use the greater-than operators), then it's easy to solve
your semantic problems. I leave that as an exercise to the gentle reader :-)

3) In another case, you may want to resort to << and <<< but it may be
unnecesary

BarZ

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

« Return to Thread: operator overloading