operator overloading

[Warner Onstine-3]

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.

--
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

[Barzilai Spinak-2]

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

[Warner Onstine-3]

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

[Tom Nichols]

Here's a quick test... let me know if there's something I missed that
doesn't fit your requirements:

class MySet implements Comparable {
  def items = []
  public int compareTo(Object other) {
    if( ! (other instanceof MySet) ) return -1

    def diff = (this.items - other.items).size
    if( diff != 0 ) return diff
    (other.items - this.items).size *-1
  }
}

def set1 = new MySet( items:[1,2,3] )
def set2 = new MySet( items:[1,2,3] )
assert set1 == set2

set2.items -= 3
assert set1 != set2
assert set2 <= set1
assert set1 > set2

set3 = new MySet( items:[1,8] )
assert set3 != set1
assert set3 >= set1

On 10/1/07, Warner Onstine <warnero@...> 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.
>
> > 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
>
>

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

    http://xircles.codehaus.org/manage_email

[Warner Onstine-3]

On 10/1/07, Tom Nichols <tmnichols@...> wrote:

> Here's a quick test... let me know if there's something I missed that
> doesn't fit your requirements:
>
> class MySet implements Comparable {
>   def items = []
>   public int compareTo(Object other) {
>     if( ! (other instanceof MySet) ) return -1
>
>     def diff = (this.items - other.items).size
>     if( diff != 0 ) return diff
>     (other.items - this.items).size *-1
>   }
> }
>
> def set1 = new MySet( items:[1,2,3] )
> def set2 = new MySet( items:[1,2,3] )
> assert set1 == set2
>
> set2.items -= 3
> assert set1 != set2
> assert set2 <= set1
> assert set1 > set2

Honestly, I'm not even sure what this is testing, sorry.

>
> set3 = new MySet( items:[1,8] )
> assert set3 != set1
> assert set3 >= set1

This last one is false it should be assert !(set3 >= set1) as not all
elements of set1 are in set3 (which is a requirement of being a
superset, or subset - whichever way you look at it).

Just for edification:
a <= b means that all elements in a are also in b (and they could be
equal as is the same as b)
a < b means that all elements in a are also in b (and they can't be equal)

Without knowing which method call is happening I can't logically tell
what I should be returning. If I had direct access to
compareLessThanEqualsTo then I could say it is either true or false
based on what I know at the time, but this way I have to guess in what
context I'm calling compareTo.

Bottom line is after looking at this some more I think it just isn't
doable in Groovy right now.

-warner

>
> On 10/1/07, Warner Onstine <warnero@...> 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.
> >
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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

[Tom Nichols]

Ah, yes I see your issue.  The > and < operators (comparison) assume that
A < B  OR B <= A will always be true.  When you're talking about sets,
A may not be a subset of B AND B might not be a subset of A.  So I
suppose the less than/ greater than does not really equate to subset
notation.  You could use leftShift and rightShift...

Try this?

class MySet {
  def items = []
  public boolean leftShift(other) {
    if( ! (other instanceof MySet) ) return false
    (this.items - other.items).size == 0
  }

  public boolean rightShift(other) {
    if( ! (other instanceof MySet) ) return -1
    (other.items - this.items).size == 0
  }

  public boolean equals( other ) {
    if( ! (other instanceof MySet) ) return -1
    (other.items - this.items).size == 0 &&
      (this.items - other.items).size == 0
  }
}

def set1 = new MySet( items:[1,2,3] )
def set2 = new MySet( items:[1,2,3] )
assert set1 == set2
assert set1 << set2 && set2 << set1
assert set1 >> set2 && set2 >> set1

set2.items -= 3   //set2 == [1,2]
assert set1 != set2
assert set2 << set1 && set1 >> set2
assert !(set1 << set2) && !(set2 >> set1)

set3 = new MySet( items:[1,8] )
assert !( set1 >> set3 ) && !( set3 >> set1 )
assert !( set1 << set3 ) && !( set3 << set1 )

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

    http://xircles.codehaus.org/manage_email

[Warner Onstine-3]

On 10/1/07, Tom Nichols <tmnichols@...> wrote:
> Ah, yes I see your issue.  The > and < operators (comparison) assume that
> A < B  OR B <= A will always be true.  When you're talking about sets,
> A may not be a subset of B AND B might not be a subset of A.  So I
> suppose the less than/ greater than does not really equate to subset
> notation.  You could use leftShift and rightShift...

Unfortunately not quite the same (especially since you can have
subsets and proper subsets). Not to mention I think the notation is
unclear in the given context (which is what the DSL is all about
anyways).

There are of course other operators I could override, but the <=, <,
=>, > make the most sense to me given the context. At this point I've
put in a comment on http://jira.codehaus.org/browse/GROOVY-1889 in
hopes that we can get this in for Groovy 2.0. It hurts to be behind
Ruby in this way (heck, even C# allows you to override these methods
specifically).

Thanks for all the help, just sorry that I wasn't mistaken.

-warner

>
> Try this?
>
> class MySet {
>   def items = []
>   public boolean leftShift(other) {
>     if( ! (other instanceof MySet) ) return false
>     (this.items - other.items).size == 0
>   }
>
>   public boolean rightShift(other) {
>     if( ! (other instanceof MySet) ) return -1
>     (other.items - this.items).size == 0
>   }
>
>   public boolean equals( other ) {
>     if( ! (other instanceof MySet) ) return -1
>     (other.items - this.items).size == 0 &&
>       (this.items - other.items).size == 0
>   }
> }
>
> def set1 = new MySet( items:[1,2,3] )
> def set2 = new MySet( items:[1,2,3] )
> assert set1 == set2
> assert set1 << set2 && set2 << set1
> assert set1 >> set2 && set2 >> set1
>
> set2.items -= 3   //set2 == [1,2]
> assert set1 != set2
> assert set2 << set1 && set1 >> set2
> assert !(set1 << set2) && !(set2 >> set1)
>
> set3 = new MySet( items:[1,8] )
> assert !( set1 >> set3 ) && !( set3 >> set1 )
> assert !( set1 << set3 ) && !( set3 << set1 )
>
> ---------------------------------------------------------------------
> 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

[Barzilai Spinak-2]

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