Implicit 'this' return for void methods

Jochen Theodorou blackdrag at gmx.org
Thu Mar 27 20:26:50 UTC 2014


Am 27.03.2014 20:22, schrieb Steven Schlansker:
>
> On Mar 27, 2014, at 9:35 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
>
>> Am 26.03.2014 16:51, schrieb Guy Steele:
>> [...]
>>> I am wholeheartedly in favor of allowing “chaining” of dotted expressions such as
>>>
>>>     CharBuffer.allocate(26).position(2).put("C").position(25).put("Z”)
>>
>> this also shows a potential point of critic this proposal will have to find arguments against. This style highly encourages mutation of the object, which is not very functional. Since java8 java tries to be more functional, thus this idea would be totally against this new line.
>>
>> I leave it to you guys if this is even a valid argument ;)
>
> It would be much easier to convince people to do less mutation if the language had support for the Builder pattern or freezing objects.

I wanted to counter that people would probably complain about the huge 
amount of objects you create, but actually you can do this with a helper 
class producing a dummy, that then becomes the final object of the real 
class once you freeze or otherwise fixate it. Well, the details don't 
really matter. But yes, I agree... some language support here would 
help, though not sure how that would look like...

> Currently working with nontrivial immutable objects quickly leads to a lot of boilerplate code that requires frustrating maintenance every time the object definition changes.

yeah, with the approach I sketched I can totally see that.

> Adding both the implicit ‘this’ proposal as well as some syntax enhancements for immutable objects would strengthen the Java language quite a bit, in my opinion :)

And here I fail. If you need special support for the builder and freezer 
to produce some helper or something already, then you don't need the 
return 'this' for void at all. The helper would be generated and thus 
already have all the bits you want. Right now I am actually wondering if 
I should add that as a transform to Groovy. But well, this is Java.

For the part with immutable I agree again of course.

byeJochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org




More information about the core-libs-dev mailing list