Return 'this' proposal

Matthias Ernst matthias at
Wed Mar 18 02:46:06 PDT 2009

On Wed, Mar 18, 2009 at 1:07 AM, Reinier Zwitserloot
<reinier at> wrote:
> Joe,
> What's the coin viability for a proposal that does NOT change the type
> system, but just introduces syntax sugar that translates:
> expression.setBar().setBaz();
> to:
> TypeOfExpression $unique = expression;
> $unique.setBar();
> $unique.setBaz();

I very much like that. In fact I had a similar proposal up almost two
years ago:

It had one big downside: it only covered void methods which was both
limiting and brittle, so I didn't pursue it further.

Your proposal requires modification to the callee when it should be
treated as a cascadable method. I think this is pretty invasive.
Instead, I've come to the conclusion that it should exclusively be a
callee-side mechanism, exactly like smalltalk does it, that specifies
"call again on the same receiver instead of the return value".

It requires using a different syntax for a cascaded invocation which I
actually like.

In ST they use ";"

result = Message newBuilder x: x;
                                           y: y;
                                           z: z;

In Java, one could for example use multiple dots:

Message m =

Or a "->" operator? It actually has a nice "and then" look to it.



> where the setBar() method has a void return type, but has also been
> ktited out with a flag that indicates its legal for call sites to do
> the syntax sugar transformation above? The way this would work is very
> similar to varargs: The method with the 'varargs flag' really doesn't
> do anything special other than have a flag. It's the callers that do
> all the work.
> There are backwards compatibility issues, because most of the code
> that wants to 'return this' currently does not return void, it instead
> returns its own type, but I have one strategy for dealing with that
> issue that is simple and doesn't introduce any new keywords -
> basically, you get to add the flag to any method, and any callers will
> check if the type of the expression is tighter than the return type.
> If so, then the type of the returned value of the call is similarly
> tightened. In trade, setting the flag requires the java code to always
> "return this" for all return statements; anything else is an instant
> compiler error. The flag is set by adding 'this' as a keyword to the
> method's modifier section. This modifier is strictly inherited. So:
> public abstract class MyBuilder {
>     public this MyBuilder setFoo(int foo) {
>         return this;
>     }
> }
>  --Reinier Zwitserloot
> On Mar 17, 2009, at 23:48, Joseph D. Darcy wrote:
>> Marek Kozieł wrote:
>>> 2009/3/17 Joseph D. Darcy <Joe.Darcy at <mailto:Joe.Darcy at
>>> >>
>>>    This 'this' proposal remains vague and imprecise.
>>>    Including this type/self type in a language is a continuing area
>>>    of study; for example, see the recent paper
>>>    "Matching ThisType to Subtyping," Chieri Saito and Atsushi
>>>    Igarashi, Kyoto University, Japan, ACM SAC 2009.
>>>    There are open bugs requesting this capability. For example typing
>>>    " <> this type" into a popular
>>>    search engine quickly yields, amongst other hits,
>>>    6479372 Add self types (type of 'this' aka ThisClass) to the
>>> language
>>>    This bug discusses the size of the type system impact of this
>>>    change, a magnitude far too large for Project Coin.
>>>    There is no need to submit further refinements of this idea; any
>>>    proposal along the lines of adding a this type will be out of
>>>    scope for Project Coin.
>>>    -Joe
>>> I'll check it, but I'm afraid that introducing 'This' type will be
>>> impossible for Java and for all other languages with Inheritance,
>>> or I
>>> would say it's possible but conditions would be huge.
>>> return 'this':
>>> - Idea is quite simple: you use object from left side of dot as
>>> returned from method, it's the same quite idea with converting void
>>> ->
>>> this, but allowed only when it's written directly.
>>> - Byte-code for that is other story and I'm not sure how much
>>> limitation this contains.
>>> Maybe you cold while what problems you see (that could help)?
>> As the author and submitter of a proposal, it is your responsibility
>> to
>> research, understand, and explain the consequences and implications of
>> your proposal.
>> -Joe

More information about the coin-dev mailing list