closures after all?

[Reinier Zwitserloot]

Having to litter a barch of static / extension imports in each source  
file is at least as dubious, from a perfectionist's point of view, as  
having ARM not work on some rarely used disposable types.

What exactly would, say, an ARM-guarded OutputStream look like with  
your idea, Neal?

  --Reinier Zwitserloot

Need to receive donations via the web?
Check http://tipit.to/

On 20 nov 2009, at 20:26, Neal Gafter <neal at gafter.com> wrote:

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