closures after all?
markmahieu at googlemail.com
Fri Nov 20 07:14:49 PST 2009
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 ;-)
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.
> Joshua Bloch wrote:
>> 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.
>> 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
>>> 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
>>> do not implement this protocol, but by providing static factory methods
>>> 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.
More information about the coin-dev