closures after all?

[Neal Gafter]

Josh-

The extension-method-based approach enables ARM to be retrofitted onto *all
*of the use cases we've identified (not just some), and without changing any
of those existing types.  You've argued repeatedly that language changes
that require changes to many existing APIs are questionable, so based on
your criterion it is simpler.

Cheers,
Neal

On Thu, Nov 19, 2009 at 4:53 PM, Joshua Bloch <jjb at google.com> 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
>>
>> On Thu, Nov 19, 2009 at 12:46 AM, Mark Mahieu <markmahieu at googlemail.com
>> >wrote:
>>
>> > *sigh*
>> >
>> > I suppose I should have guessed that a deliberately silly bit of code
>> like
>> > this would get linked to or reproduced in edited form elsewhere (without
>> my
>> > 'tongue-in-cheek' disclaimer).
>> >
>> > So, for the bloody record:
>> >
>> > 1) I have absolutely no idea whether it will ever be considered valid
>> Java.
>> > 2) Even if it will be valid, I don't think it's remotely representative
>> of
>> > code which will use ARM, or closures, or both.
>> > 3) Even if it will be valid, and someone decides to write something like
>> > this, I don't think it will be hard to understand what it does.
>> > 4) 'YOUR HEAD A SPLODE' refers to the mixing of ARM and closures, which
>> > some on this list may find mildly ironic.  It was not intended as
>> serious
>> > commentary on the potential uses of those features, individually or in
>> > tandem.  If I have serious concerns to raise at some point, I probably
>> won't
>> > choose to back them up by quoting an animated mexican wrestler.
>> >
>> > On the other hand, I was serious about it being interesting to
>> investigate
>> > the interaction between the various language features.
>> >
>> > Sincere apologies for any confusion (!)
>> >
>> > Mark
>> >
>> >
>> > On 18 Nov 2009, at 23:49, Mark Mahieu wrote:
>> >
>> > > Well it'll be interesting to see the official details, and (to bring
>> it
>> > back on topic) see how it interacts with Coin's language enhancements.
>> > >
>> > > // tongue in cheek
>> > > try (Closeable closure = #() { System.out.println("YOUR HEAD A
>> SPLODE");
>> > }) {
>> > >       // ...
>> > > }
>> > >
>> > >
>> > > Mark
>> >
>> >
>> >
>>
>>
>