Overloading comparison operators

[Jörg Staudemeyer-2]

Hi

are there any plans to change handling of comparison operators in a later version of Groovy?

Currently, comparison operators only apply to classes that implement the Comparable interface and are mapped to the compareTo() method. compareTo() method must return an integer value, as dictated by the interface, but the result of a comparison expression is always boolean.

IMO this is not consistent with handling of other operators like + and << that always map to a specific method returning an arbitrary result value. As a result, usage of comparison operators in DSLs is quite restricted.

What I would like to have is something like this:

a < b  ==> a.smallerThan(b)
a =<b ==> a.smallerThanEqualOrEqualTo(b)
a!=b ==> a.notEqualTo(b)

and so on. All this methods should normally return a boolean value, but in certain circumstances, like in a DSL, can also return something else.

Implement this should not be particularly difficult, one could simply create default implementations of these methods for Comparable in DefaultGroovyMethods doing something constistent with current behaviour.

What do you think?

-Jörg

[Jochen Theodorou]

Jörg Staudemeyer schrieb:
> Hi
>
> are there any plans to change handling of comparison operators in a
> later version of Groovy?

there are plans to change it for 2.0, there are not yet plans on how to
exactly do that. I am thinking about removing the dependency on the
Compareable method and just go with methods that might be defined or
not, like we do with plus, minus, shift, etc.

> Currently, comparison operators only apply to classes that implement the
> Comparable interface and are mapped to the compareTo() method.
> compareTo() method must return an integer value, as dictated by the
> interface, but the result of a comparison expression is always boolean.
 >
> IMO this is not consistent with handling of other operators like + and
> << that always map to a specific method returning an arbitrary result
> value. As a result, usage of comparison operators in DSLs >

I agree. It was done in early days for speed. Now that Groovy is faster
it should be changed... but the thought of letting <,> return something
that is not boolean didn't occur to me yet... but true, for a DSL this
might be very interesting. You could leave a comment in
http://jira.codehaus.org/browse/GROOVY-2756

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email

[glaforge]

By the way, I'd be curious to know what you have in mind?
What kind of DSL you would write with these operators?

On Thu, Jul 17, 2008 at 11:03 AM, Jörg Staudemeyer
<jstaudemeyer@...> wrote:

> Hi
>
> are there any plans to change handling of comparison operators in a later
> version of Groovy?
>
> Currently, comparison operators only apply to classes that implement the
> Comparable interface and are mapped to the compareTo() method. compareTo()
> method must return an integer value, as dictated by the interface, but the
> result of a comparison expression is always boolean.
>
> IMO this is not consistent with handling of other operators like + and <<
> that always map to a specific method returning an arbitrary result value. As
> a result, usage of comparison operators in DSLs is quite restricted.
>
> What I would like to have is something like this:
>
> a < b  ==> a.smallerThan(b)
> a =<b ==> a.smallerThanEqualOrEqualTo(b)
> a!=b ==> a.notEqualTo(b)
>
> and so on. All this methods should normally return a boolean value, but in
> certain circumstances, like in a DSL, can also return something else.
>
> Implement this should not be particularly difficult, one could simply create
> default implementations of these methods for Comparable in
> DefaultGroovyMethods doing something constistent with current behaviour.
>
> What do you think?
>
> -Jörg
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[Jörg Staudemeyer-2]

I'm experimenting with a kind of query language. In this language, arithmetic and logical expression shall result in a description of the expression, not in the result of the actual expression evaluation itself. Hence the operator method should be able to return something at will and not be restricted to a certain result type.

Just as an example, think of the following.

(A op B) results in: new Operation(A,B,'op')

With arithmetic operators, this works perfectly using an operator method like this:

def plus(otherValue)  { new Operation(this,otherValue,'plus') }

or in a generic way:

def invokeMethod(String name, Object args) {
    if (args.size()==1) { return new Operation(this,args[0]),name) }
    ...
}

With Groovy's comparison operators there is currently no chance to do something like that.

-Jörg
 

2008/7/17 Guillaume Laforge <glaforge@...>:

By the way, I'd be curious to know what you have in mind?
What kind of DSL you would write with these operators?

On Thu, Jul 17, 2008 at 11:03 AM, Jörg Staudemeyer
<jstaudemeyer@...> wrote:
> Hi
>
> are there any plans to change handling of comparison operators in a later
> version of Groovy?
>
> Currently, comparison operators only apply to classes that implement the
> Comparable interface and are mapped to the compareTo() method. compareTo()
> method must return an integer value, as dictated by the interface, but the
> result of a comparison expression is always boolean.
>
> IMO this is not consistent with handling of other operators like + and <<
> that always map to a specific method returning an arbitrary result value. As
> a result, usage of comparison operators in DSLs is quite restricted.
>
> What I would like to have is something like this:
>
> a < b  ==> a.smallerThan(b)
> a =<b ==> a.smallerThanEqualOrEqualTo(b)
> a!=b ==> a.notEqualTo(b)
>
> and so on. All this methods should normally return a boolean value, but in
> certain circumstances, like in a DSL, can also return something else.
>
> Implement this should not be particularly difficult, one could simply create
> default implementations of these methods for Comparable in
> DefaultGroovyMethods doing something constistent with current behaviour.
>
> What do you think?
>
> -Jörg
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology

http://www.g2one.com

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

   http://xircles.codehaus.org/manage_email

--
A Groovy user

[glaforge]

Another way of achieving this is through the AST transformations you
can find in Groovy 1.6-beta-1 and Trunk.
For those kind of advanced ideas, it may be a better and more flexible
choice, although it may be a bit more complex to us (manipulating the
AST).


On Thu, Jul 17, 2008 at 12:26 PM, Jörg Staudemeyer
<jstaudemeyer@...> wrote:

> I'm experimenting with a kind of query language. In this language,
> arithmetic and logical expression shall result in a description of the
> expression, not in the result of the actual expression evaluation itself.
> Hence the operator method should be able to return something at will and not
> be restricted to a certain result type.
>
> Just as an example, think of the following.
>
> (A op B) results in: new Operation(A,B,'op')
>
> With arithmetic operators, this works perfectly using an operator method
> like this:
>
> def plus(otherValue)  { new Operation(this,otherValue,'plus') }
>
> or in a generic way:
>
> def invokeMethod(String name, Object args) {
>     if (args.size()==1) { return new Operation(this,args[0]),name) }
>     ...
> }
>
> With Groovy's comparison operators there is currently no chance to do
> something like that.
>
> -Jörg
>
>
> 2008/7/17 Guillaume Laforge <glaforge@...>:
>>
>> By the way, I'd be curious to know what you have in mind?
>> What kind of DSL you would write with these operators?
>>
>> On Thu, Jul 17, 2008 at 11:03 AM, Jörg Staudemeyer
>> <jstaudemeyer@...> wrote:
>> > Hi
>> >
>> > are there any plans to change handling of comparison operators in a
>> > later
>> > version of Groovy?
>> >
>> > Currently, comparison operators only apply to classes that implement the
>> > Comparable interface and are mapped to the compareTo() method.
>> > compareTo()
>> > method must return an integer value, as dictated by the interface, but
>> > the
>> > result of a comparison expression is always boolean.
>> >
>> > IMO this is not consistent with handling of other operators like + and
>> > <<
>> > that always map to a specific method returning an arbitrary result
>> > value. As
>> > a result, usage of comparison operators in DSLs is quite restricted.
>> >
>> > What I would like to have is something like this:
>> >
>> > a < b  ==> a.smallerThan(b)
>> > a =<b ==> a.smallerThanEqualOrEqualTo(b)
>> > a!=b ==> a.notEqualTo(b)
>> >
>> > and so on. All this methods should normally return a boolean value, but
>> > in
>> > certain circumstances, like in a DSL, can also return something else.
>> >
>> > Implement this should not be particularly difficult, one could simply
>> > create
>> > default implementations of these methods for Comparable in
>> > DefaultGroovyMethods doing something constistent with current behaviour.
>> >
>> > What do you think?
>> >
>> > -Jörg
>> >
>> >
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> G2One, Inc. Vice-President Technology
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> A Groovy user

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[Jörg Staudemeyer-2]

2008/7/17 Jochen Theodorou <blackdrag@...>:

 

I agree. It was done in early days for speed. Now that Groovy is faster it should be changed... but the thought of letting <,> return something that is not boolean didn't occur to me yet... but true, for a DSL this might be very interesting. You could leave a comment in http://jira.codehaus.org/browse/GROOVY-2756

Thank you. Comment has been added.
-Jörg

[Jörg Staudemeyer-2]

2008/7/17 Guillaume Laforge <glaforge@...>:

Another way of achieving this is through the AST transformations you
can find in Groovy 1.6-beta-1 and Trunk.
For those kind of advanced ideas, it may be a better and more flexible
choice, although it may be a bit more complex to us (manipulating the
AST).

I like Groovy because it makes otherwise complicated tasks so simple, sometimes to a surprising amount.
For AST manipulations, I'm afraid I need some training course before... ;-)
-Jorg