hg: lambda/lambda/langtools: Implemented features are:

[Rémi Forax]

Le 30/07/2010 20:47, Joe Darcy a écrit :
> Maurizio Cimadamore wrote:
>    
>> On 30/07/10 19:23, Osvaldo Doederlein wrote:
>>
>>      
>>> 2010/7/30<maurizio.cimadamore at oracle.com>:
>>>
>>>
>>>        
>>>> *) Effectively final analysis
>>>> Local variables that are never assigned can now be referenced from a lambda body.
>>>>
>>>>
>>>>          
>>> Slightly offtopic, but... will the effectively-final feature benefit
>>> exception handling too (final rethrow and multi-catch, both currently
>>> requiring explicit 'final' declatration of the caught exception
>>> reference)?
>>>
>>>
>>>        
>> I think this is an interesting suggestion.
>> Removing the need for the 'final' in the improved 'rethrow' feature is
>> probably worthwhile. On the other hand I don't think that removing final
>> from disjunctive type-parameters would be a good idea: the final is
>> there because you want to forbid that variable to be re-assigned (note
>> that the original proposal was orthogonal to actual support of
>> disjunctive types in the type-system).
>>
>> On the other hand, since now we support even disjunctive types (because
>> of exception transparency) I guess we could improve that as well:
>> quoting from the original improved try/catch proposal:
>>
>> " To avoid the need to add support for general disjunctive types, but
>> leaving
>> open the possibility of a future extension along these lines, a catch
>> parameter whose type has more than one disjunct is required to be declared *
>> final*."
>>
>> I guess we will be able to spot more of these inter-feature dependencies
>> as we move forward ;-)
>>
>>
>>      
> Yes, as a general comment, the specifications and implementation
> strategies of a number of Project Coin feature should be reexamined to
> take advantage of Project Lambda features once they are available.
> Another example is using defender methods as an implementation technique
> to provide [] access to collections.
>
> -Joe
>    

Not sure it's a good idea.
This may require a different bootstrap method for each Collection/Map
interfaces.

And worst, you will allow users to be able to code two different semantics
for a[i] and a.get(i).

Rémi