Primitives in Generics (+ the meaning of this)

[Rémi Forax]

Le 16/07/2010 20:45, Reinier Zwitserloot a écrit :
> The rather obvious answer would seem to be that implicit this refers to the
> inner object, but explicit this defaults to the outer object. You can still
> get an explicit this referencing the inner object by using the SAM type as a
> qualifier.
>
> Thus:
>
> public class Example {
>      public void cancel() { System.out.println("OUTER"); }
>
>      public void runMe() {
>          TimerTask t = { ->
>              cancel(); //LINE 1
>              this.cancel(); //LINE 2
>              Example.this.cancel(); //LINE 3
>              TimerTask.this.cancel(); //LINE 4
>          };
>      }
> }
>
> In the above example, LINE 1 and LINE 4 cancel the timertask, whereas LINE 2
> and LINE 3 just print "OUTER" to sysout.
>
> As has been said, everything is going to either be hard to understand or not
> the thing one would expect in certain situations, and this is of course no
> different - now there's a difference between unqualified invocation and
> this-qualified invocation for method calls, which doesn't normally happen in
> java land. In my purely personal opinion on what's going to do the right
> thing and be the least surprising the most often, this one nevertheless
> wins.
>
> NB: As per the usual lexical scoping rules, if this was say a Runnable and
> not a TimerTask, then LINE 1 would also print 'OUTER'.
>
>   --Reinier Zwitserloot
>    

And what about:
class A {
   public static void main(String[] args) {
     A a = { ->
        A.this;
     };
   }
}

Rémi

>
>
> On Fri, Jul 16, 2010 at 7:07 PM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>
>    
>>> Regardless of that, do you aggree that the statistical evidence, prepared
>>>        
>> by some members of this list, showed that usage of explicit and implicit
>> "this" inside anonymous inner SAM subclass creation expressions is
>> practically non-existent and is actualy "in the way" of using outer.this
>> and/or outer instance members (even a cause of bugs in JDK itself)?
>>
>> No, I don't agree with this.  What we have is, basically, arguments over
>> which
>> use cases are more important and which error modes are worse, which are
>> almost
>> always just opinion contests, just like syntax discussions about which
>> alternative "looks more like Java".  Issues such as the one Josh raised
>> (where
>> TimerTask wants to call cancel()) come up with some frequency; so do
>> accidental shadowing of methods like toString() in inner classes.  This
>> generally just comes down to a "which error would you rather have"
>> question.
>> And, given that inner classes *already* suffer from the accidental
>> shadowing
>> problem, creating a mechanism that goes the other way (even if the other
>> way
>> is absolutely right!) is even more confusing for Java developers, who now
>> have
>> to keep track of two separate and inconsistent bits of puzzlerhood.
>>
>> That said, the questions you raise here (and in your next e-mail) are fair
>> and
>> we've already planned to devote some thought to it -- but not now, because
>> we've got other things that demand our attention more urgently, such as
>> refining and implementing the features that are already in the must-have
>> column.
>>
>>
>>
>>      
>