Return 'this' proposal

[Matthias Ernst]

On Wed, Mar 18, 2009 at 1:07 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> 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: http://www.mernst.org/blog/rss.xml#Cascading-First-Patch

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;
                                           build.

In Java, one could for example use multiple dots:

Message m =
  Message.newBuilder()
    .setX(x)
    ...setY(y)
    ...setZ(z)
    ...build();

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

.setX(x)
->setY(y)
->setZ(z)
->build();

Matthias


>
> 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 sun.com <mailto:Joe.Darcy at sun.com
>>> >>
>>>
>>>    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
>>>    "site:bugs.sun.com <http://bugs.sun.com> 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
>>
>>
>
>
>