« Return to Thread: operator overloading
Re: operator overloading
by Barzilai Spinak-2
::
Rate this Message:
Some points to consider:
1) In order to use the <, <=, >, >= operators, the operands (or at least
the left operand) must implement Comparable
2) If the implement Comparable, they must have the method: public int
compareTo(Object other)
3) This method returns an int, which normally has the semantics that:
* it must be less than zero if this object is less than "other"
* it must be greater than zero if this object is greater than "other"
* it must be zero if this object is equal to "other" (which, for
consistency reaons, should behave like the equals method in this case)
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
5) Even though compareTo returns an integer, the comparator operators
return a boolean (you normally won't call compareTo directly).
6) There are (or used to be) some weird cases for equals that have been
discussed in the list in the past but I don't remember the details now :-)
One last question, when you say (a <= b), do you want to DECLARE a
relation or TEST for its truth?
I hope this helps.
BarZ
Warner Onstine wrote:
> Ok, I'm having some amount of difficulty with trying implement some
> operator overloading and am hoping someone has some ideas on how to
> fix these issues.
>
> Here's what I'm trying to do (and didn't think it would be this
> difficult). I want to implement some Set notation like the following:
> a is a subset of b (a <= b)
> a is a proper subset of b (a < b)
> a equals b (a == b)
>
> and some Set operations:
> a union b (a + b)
> a intersect b (a / b)
> a complement b (a - b)
>
> For reference set notation and operations can be found on wikipedia
> (http://en.wikipedia.org/wiki/Naive_set_theory).
>
> Now that I have the ground rules laid here are some of the issues I'm
> encountering:
> 1) a == b, do this by overriding the equals method, right? Nope, the
> compareTo(object) method gets called instead
> 2) a <= b, i have to implement Comparable to use the compareTo()
> method (which by the way is not at all mentioned here -
> http://groovy.codehaus.org/Operator+Overloading). But the compareTo()
> method only returns -1, 0, or 1 (not true or false, which is needed
> for my tests and would make sense to me)
>
> Please tell me I'm wrong, I would love to be wrong on this. But this
> seems overly complicated for overriding some of these methods. I know
> that the leftShift operator is not nearly as difficult (and seems to
> be the one that everyone goes after).
>
> I'm attaching my test class and actual class I'm using. I also tried
> initially to use ExpandoMetaClass to do this but kept getting argument
> type mismatches when I called. This led me down my current path of
> using my own class as originally I wanted to use this on all
> Collections.
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
1) In order to use the <, <=, >, >= operators, the operands (or at least
the left operand) must implement Comparable
2) If the implement Comparable, they must have the method: public int
compareTo(Object other)
3) This method returns an int, which normally has the semantics that:
* it must be less than zero if this object is less than "other"
* it must be greater than zero if this object is greater than "other"
* it must be zero if this object is equal to "other" (which, for
consistency reaons, should behave like the equals method in this case)
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
5) Even though compareTo returns an integer, the comparator operators
return a boolean (you normally won't call compareTo directly).
6) There are (or used to be) some weird cases for equals that have been
discussed in the list in the past but I don't remember the details now :-)
One last question, when you say (a <= b), do you want to DECLARE a
relation or TEST for its truth?
I hope this helps.
BarZ
Warner Onstine wrote:
> Ok, I'm having some amount of difficulty with trying implement some
> operator overloading and am hoping someone has some ideas on how to
> fix these issues.
>
> Here's what I'm trying to do (and didn't think it would be this
> difficult). I want to implement some Set notation like the following:
> a is a subset of b (a <= b)
> a is a proper subset of b (a < b)
> a equals b (a == b)
>
> and some Set operations:
> a union b (a + b)
> a intersect b (a / b)
> a complement b (a - b)
>
> For reference set notation and operations can be found on wikipedia
> (http://en.wikipedia.org/wiki/Naive_set_theory).
>
> Now that I have the ground rules laid here are some of the issues I'm
> encountering:
> 1) a == b, do this by overriding the equals method, right? Nope, the
> compareTo(object) method gets called instead
> 2) a <= b, i have to implement Comparable to use the compareTo()
> method (which by the way is not at all mentioned here -
> http://groovy.codehaus.org/Operator+Overloading). But the compareTo()
> method only returns -1, 0, or 1 (not true or false, which is needed
> for my tests and would make sense to me)
>
> Please tell me I'm wrong, I would love to be wrong on this. But this
> seems overly complicated for overriding some of these methods. I know
> that the leftShift operator is not nearly as difficult (and seems to
> be the one that everyone goes after).
>
> I'm attaching my test class and actual class I'm using. I also tried
> initially to use ExpandoMetaClass to do this but kept getting argument
> type mismatches when I called. This led me down my current path of
> using my own class as originally I wanted to use this on all
> Collections.
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: operator overloading
| Free embeddable forum powered by Nabble | Forum Help |
