Preparing for the 0.2 draft

Alex Blewitt alex.blewitt at gmail.com
Fri Jan 29 01:20:18 PST 2010


Sorry, sent slightly too soon. The other example I was going to cite  
was the use of Visitors, such as those for recursiveky processing an  
ADT. These typically both visit nodes and maintain state as they do  
so, even if it is not used (line number info/range etc)

I don't believe that necessarily these are important enough cases to  
merit throwing an idea out, but the visitor pattern is fairly common  
in e.g. IDEs.

Lastly, say we allow SAM on (abstract) classes iff they have no (non- 
final) fields. We then end up with an evolution problem in that L can  
extend A and be compiled, but then a field is added to A giving A'. So  
it won't compile any more but now we have a problem with the compiled  
L, which may be in a different file. The same holds for removing the  
(implicit) default constructor.

Alex

Sent from my (new) iPhone

On 29 Jan 2010, at 09:11, Alex Blewitt <alex.blewitt at gmail.com> wrote:

> If we admit certain classes of (ahem) classes for SAM then should  
> there be a diffrenve between those with final vs non-final fields?
>
> One common (stats awaiting) pattern I've seen is to have a SAM class  
> to calculate a running total of e.g. sum of a list.
>
> public abstract class Fold {
>  private int start;
>  public abstract int op(int, int);
> }
>
> list.apply(r = #int(int a, int b) { return a+b; })
> r.getTotal()
>
>
> Sent from my (new) iPhone
>
> On 29 Jan 2010, at 08:56, Alex Buckley <Alex.Buckley at Sun.COM> wrote:
>
>> Many thanks for everyone's comments on the 0.1 draft. The "foo.()"
>> invocation syntax looks like a winner, and I am seriously considering
>> rearranging the function type syntax to have argument types first.
>> Requiring a lambda expression to denote its return type is also
>> increasingly appealing. SAM classes are staying for now.
>>
>> The discussion of transparent 'this' v. non-transparent 'this' comes
>> down to the question of what a lambda in Java is for. (Zdenek  
>> Tronicek
>> ably made this point earlier.) Part of the answer lies in  
>> understanding
>> when to use an anonymous inner class and when to use a lambda
>> expression. A step towards that understanding would be knowing how
>> anonymous inner classes are used today.
>>
>> It would be very interesting if list members could provide the  
>> following
>> statistics for codebases with which they are familiar:
>>
>> - What %age of anonymous inner classes declare a single non-Object  
>> method?
>> - What %age of single-method anonymous inner classes declare fields?
>> - What %age of single methods in anonymous inner classes use 'this'?
>> - What %age of single methods in anonymous inner classes recurse?
>> - Are the %ages different for anonymous inner classes that  
>> implement an
>> interface v. that extend a class ?
>>
>> (As well as anonymous inner classes, any utility class that
>> implements/extends a SAM type is of interest, such as this nested  
>> class
>> from the extra166y.ParallelArray Javadoc:
>>  static final class IsSenior implements Predicate<Student> {
>>     public boolean op(Student s) { return s.credits > 90; }
>>   }
>> )
>>
>> Alex
>>


More information about the lambda-dev mailing list