next »

[BrazilianBoy]

Why the Tuple.. classes don't return themselves when methods like tuple.addX(5) are called?

This would be very useful, and would allow clever recursive method calls like:

Code:

body.setPosition(body.getPosition().addX(0.5f).addZ(0.5f));

It also contributes to a clean, compact, and simpler code.

Lucas.

[Marvin Fröhlich]

Well, I really don't like this kind of code trick. It leads to less readability for those, who don't know the specific piece of code. But I could add this to the methods, if anyone wants to use it. It won't harm the execution speed of these methods, IFAIK.

Marvin

[Marvin Fröhlich]

I have added those self-returners.

Marvin

[BrazilianBoy]

I have added those self-returners.

Thank you very much 

[Mathias 'cylab' Henze]

Well, I really don't like this kind of code trick.

It's not a code trick since it is exact the same way how a "+=" operator has to be defined in a language that supports operator overloading.

[Marvin Fröhlich]

It's not a code trick since it is exact the same way how a "+=" operator has to be defined in a language that supports operator overloading.

Yeah, but would you like this one:

Code:

a += b = c;

?

Marvin

[Mathias 'cylab' Henze]

Err... yes 

But you right, that this is a more tricky example, since it cannot be implemented as

Code:

a.add(b).set(c)

but has to be

Code:

a.add(b.set(c))

which resembles a+=(b+c) because of higher priority of the = operator. However, I always do those brackets anyway for clearity 

Having said that, I think methods like set() are a different kind of thing than add(), mul() etc.