Re: promoting closure-valued slots to methods

On 19 Feb 2005, at 03:15, John Rose wrote:
> If we're going to have a clear separation between properties and 
> methods, let's look at the closure-to-method promotion in a bit more 
> detail.
> Maybe it shouldn't be turned on by default for and and all Groovy 
> classes or imported Java classes.
> (If a class implements MOP methods, it can selectively promote 
> anything to anything else, of course.)
>
> I'm aware of three use-cases for the treatment of closure-slots as 
> methods.
>
> 1. A map has a slot (quasi-field) named for each of its keys.  If such 
> a slot is closure-valued, it can serve also as a method.
> Combined with duck typing, this gives a natural way to write anonymous 
> class instances, Groovy style:
>
>   [hasNext: {in.available > 0}, next: {in.read}] as Iterator
>
> 2. More complicated objects with expandable slot sets can do the same 
> trick.
>
> 3. Closures can serve as local methods (in block scopes) under this 
> rule (creatively applied to local variables instead of slots):
>
>   {
>     int x = 0  // local saturating counter
>     def bump_x = { if (x < 10)  ++x }
>     ... ; bump_x();  ... ; bump_x(); ...
>   }
>
> It may be that all of these are special cases, and that there's no 
> need for baking the closure-slot => method promotion into the basic 
> language.
> With #1, maps are already special-cased (via the MOP), so adding 
> methods is easy.
> With #2, again there already MOP-level customization.

Agreed with these; it can be a pure MOP issue

> With #3, it could be just a special rule that pertains to unqualified 
> names (say).

Yes. #3 is the one with really causes a language change (rather than 
just the MOP doing the work). It does seem natural though; to treat 
closure variables as methods and invoke them. If we're worried about 
this, we could punt and enforce the bump_x.call() syntax, but it does 
feel natural to invoke closures as methods; given that they are 
unqualified names, it should be easy to check etc.

The biggest complication/issue in the past with invoking closures in 
this way was often with markup; where unqualified names could get mixed 
up a little with markup - but thats more an issue of markup needing 
fixing from a name scoping sense.

James
-------
http://radio.weblogs.com/0112098/