Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 365717 - [xtend] allow operators to be commutative
Summary: [xtend] allow operators to be commutative
Status: CLOSED WONTFIX
Alias: None
Product: Xtend
Classification: Tools
Component: Core (show other bugs)
Version: 2.2.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-06 08:03 EST by Moritz Eysholdt CLA
Modified: 2012-03-20 11:28 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Eysholdt CLA 2011-12-06 08:03:03 EST
Operators such as "+" and "*" are commutative, i.e. (x + y) == (y + x)

Right now we have scenarios where only one direction works:

"string" + 123 // works
123 + "string" // error, incompatible types

It would be nice to have extension methods so that "+" and "*" behave commutative. Another option could be to annotate an operator to be commutative. This would make the operator implicitly available a second time with swapped LHS and RHS.
Comment 1 Sebastian Zarnekow CLA 2011-12-06 08:07:35 EST
Since operators are just aliases for method invocations. Their implementation contract does not specify whether they are commutative, may cause side effects, symetry and the like. That's why I don't like the idea to automagically swap arguments or something.

Though, having an ObjectExtension operator_plus(Object, String) sounds appealing to me.
Comment 2 Moritz Eysholdt CLA 2011-12-06 08:10:35 EST
(In reply to comment #1)
> Since operators are just aliases for method invocations. Their implementation
> contract does not specify whether they are commutative, may cause side effects,
> symetry and the like. That's why I don't like the idea to automagically swap
> arguments or something.

not automagically, one could annotate a method with "@Commutative".
Comment 3 Sven Efftinge CLA 2012-03-08 03:09:32 EST
Can you give an example where this would be useful?
Comment 4 Moritz Eysholdt CLA 2012-03-08 04:52:19 EST
(In reply to comment #3)
> Can you give an example where this would be useful?

To support 
3.14 + 123 
and
123 + 3.14

you currently need two methods:
operator_plus(BigDecimal left, BigInteger right) 
operator_plus(BigInteger left, BigDecimal right) 

since the addition on numbers is commutative, both methods would have to do the same.

with 
@Commutative operator_plus(BigDecimal left, BigInteger right) 
you would only need to declare the method once and xbase would know that the method's parameters may be swapped implicitly.


I have to correct myself about the first example, since addition on string an int is not commutative, since ("x" + 1) != (1 + "x") because "x1" != "1x".
Comment 5 Sven Efftinge CLA 2012-03-08 05:09:55 EST
Ok, I understand but I don't think it's worth a language-level feature.
Comment 6 Moritz Eysholdt CLA 2012-03-20 11:28:33 EDT
It was more an idea, I'm not insisting on this. I'm closing this. If somebody thinks this is an important feature, please reopen.