closures after all?

Neal Gafter neal at gafter.com
Fri Nov 20 11:26:34 PST 2009


Josh-

As you are well aware, there is controvery about which types matter.  A spec
based on extension methods can be used to support all of the types that we
discussed, not just the ones you consider to matter.

Cheers,
Neal

On Fri, Nov 20, 2009 at 11:18 AM, Joshua Bloch <jjb at google.com> wrote:

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



More information about the coin-dev mailing list