Return 'this' proposal

Jeremy Manson jeremy.manson at gmail.com
Tue Mar 17 19:48:19 PDT 2009


Hey Reinier,

I'm unclear on how that doesn't change the type system.  That is,
you've described an implementation technique that doesn't require a
change to bytecode (which is nice), but doesn't it still change
Java-the-language's type system?

Jeremy

On Tue, Mar 17, 2009 at 5:07 PM, 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();
>
>
> 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
>>
>>
>
>
>



More information about the coin-dev mailing list