closures after all?

[Joshua Bloch]

Neal,

Thanks for the explanation.  I did take a crack at the JDK, and I found that
it was straightforward to retrofit all of the types that mattered.

       Josh

On Fri, Nov 20, 2009 at 8:30 AM, Neal Gafter <neal at gafter.com> wrote:

> 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
>>> >
>>> >
>>> >
>>>
>>>
>>
>