closures after all?

[Mark Mahieu]

At the risk of sounding impatient, do you have any feeling for when we might see an initial implementation based on the current approach?

I'm just keen to see how far I can twist Josh's ARM ;-)

Mark


On 20 Nov 2009, at 09:02, Joseph D. Darcy wrote:

> Since the interface-based approach can be designed and used today, I'd 
> like to see that approach be available in the near future so experience 
> can be gained using ARM.  If another approach is later determined to be 
> superior, the approach can be changed.
> 
> -Joe
> 
> Joshua Bloch wrote:
>> Neal,
>> 
>> I'm not sure why you consider this to be simpler than the current,
>> interface-based approach to ARM blocks.  To be honest, it strikes me as a
>> bit convoluted. I'm not saying that I don't believe extension methods to be
>> a good thing, but I'm not convinced that they change the preferred approach
>> to ARM blocks.
>> 
>>     Josh
>> 
>> On Thu, Nov 19, 2009 at 3:58 PM, Neal Gafter <neal at gafter.com> wrote:
>> 
>> 
>>> I also heard a rumor about extension methods.  If so, that would suggest a
>>> much simpler approach to ARM blocks.  From
>>> http://www.javac.info/ExtensionMethods.html:
>>> 
>>> One of the biggest advantages of extension methods is that they enable more
>>> flexible extension of the language moving forward. For example, suppose a
>>> new Automated Resource Management statement were defined in terms of
>>> invoking an acquire() method, and then later invoking a release() method on
>>> the result of the earlier acquire(). Clearly existing APIs such as
>>> Closeable
>>> do not implement this protocol, but by providing static factory methods
>>> they
>>> could be made to act as if they do. Such a statement could then be easily
>>> retrofitted onto other resource APIs, such as
>>> java.util.concurrent.locks.Lock (an interface), simply by providing
>>> extension methods. This retrofitting introduces no breaking changes, since
>>> the underlying APIs are not changed.
>>> 
>>> -Neal