« Return to Thread: operator overloading
Re: operator overloading
by Warner Onstine-3
::
Rate this Message:
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.
> 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
That seems like an even worse problem (especially in my situation right now)
> 5) Even though compareTo returns an integer, the comparator operators
> return a boolean (you normally won't call compareTo directly).
Finally found that chart in GinA. But I don't know if it's going to
help me with what I *need* to do.
> 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?
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
>
> 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
>
>
--
Warner Onstine - Programmer/Author
New book on Tapestry 4!
Tapestry 101 available at
http://sourcebeat.com/books/tapestrylive.html
warner@...
http://warneronstine.com/blog
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
> 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.
> 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
That seems like an even worse problem (especially in my situation right now)
> 5) Even though compareTo returns an integer, the comparator operators
> return a boolean (you normally won't call compareTo directly).
Finally found that chart in GinA. But I don't know if it's going to
help me with what I *need* to do.
> 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?
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
>
> 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
>
>
--
Warner Onstine - Programmer/Author
New book on Tapestry 4!
Tapestry 101 available at
http://sourcebeat.com/books/tapestrylive.html
warner@...
http://warneronstine.com/blog
---------------------------------------------------------------------
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 |
