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