Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365717

Summary:	[xtend] allow operators to be commutative
Product:	[Tools] Xtend	Reporter:	Moritz Eysholdt <moritz.eysholdt>
Component:	Core	Assignee:	Project Inbox <xtend-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	sebastian.zarnekow, sven.efftinge
Version:	2.2.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Moritz Eysholdt

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

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

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

2012-03-08 03:09:32 EST

Can you give an example where this would be useful?

Comment 4 Moritz Eysholdt

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

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

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.