[groovy-jsr] Closure & Markup name resolution proposal

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[groovy-jsr] Closure & Markup name resolution proposal

jstrachan-3
Here's a summary of my thoughts post-the-GroovyOne meeting...

http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name 
+resolution+proposal

Thoughts?

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

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Closure & Markup name resolution proposal

Jochen Theodorou
[hidden email] schrieb:
> Here's a summary of my thoughts post-the-GroovyOne meeting...
>
> http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name 
> +resolution+proposal
>
> Thoughts?


I think it may be better to never match a vanilla name inside a markup
to the outer class. The benefit is, that the markup syntax redefines the
implicit this. That is an easy and clean rule for both, compiler and
reader.

I think many builder will be dynamic, so there is no difference in that
case. And if you use a static builder you can still qualify the name
with the "this" prefix if you need the outer class. This way you don't
have to know all methods and possible hiding.

An application we should always keep in mind is that here:

builder.{
   html {
     body {
       ol {
         4.times { li() }
       }
     }
   }
}

the old syntax required to write builer.li() instead of just li(). The
new version deosn't mention how to handle that case, but I expect the
same way as if li() would be a dircet child of ol. My "adjustment"
doesn't change that.

The result I see is that a method call from inside a closure is *never*
dispatched using the closure itself. For exmaple:

builder.{
   println toString()
}

will call the builder's toString() method. If the builder decides a
toString should better be resolved to the outer class, then it's
something the builder can do.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

RE: Closure & Markup name resolution proposal

Dierk König
In reply to this post by jstrachan-3
Good and clean proposal :-)

Two points:
- We will always have a distinction between closures and blocks
  as long as the 'return' problem is not solved.
  ('return' in closures leaves the closure while in blocks
   it leaves the surrounding method)
  Also: inlining for performance cannot be done because of that.
- How is a 'static' Builder supposed to expose it's 'static' names?
  Note that e.g. SwingBuilder.class doesn't have this info in its
  AST. Do we need a convention like demanding static
  fields/Properties/methods for this purpose?

cheers
Mittie
 

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Dienstag, 29. November 2005 9:43
> To: [hidden email]
> Subject: [groovy-jsr] Closure & Markup name resolution proposal
>
>
> Here's a summary of my thoughts post-the-GroovyOne meeting...
>
> http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name 
> +resolution+proposal
>
> Thoughts?
>
> James
> -------
> http://radio.weblogs.com/0112098/
Reply | Threaded
Open this post in threaded view
|

Re: Closure & Markup name resolution proposal

jstrachan
In reply to this post by Jochen Theodorou
On 29 Nov 2005, at 09:07, Jochen Theodorou wrote:

> [hidden email] schrieb:
>> Here's a summary of my thoughts post-the-GroovyOne meeting...
>> http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name 
>> +resolution+proposal
>> Thoughts?
>
> I think it may be better to never match a vanilla name inside a  
> markup to the outer class. The benefit is, that the markup syntax  
> redefines the implicit this. That is an easy and clean rule for  
> both, compiler and reader.
>
> I think many builder will be dynamic, so there is no difference in  
> that case. And if you use a static builder you can still qualify  
> the name with the "this" prefix if you need the outer class. This  
> way you don't have to know all methods and possible hiding.

Yeah - it does seem like the simplest possible solution (requiring a  
prefix with dot to break out of markup) and might be the easiest  
thing for users to grok; that way they don't have to mentally know  
what all the names are. Plus a dynamic builder could hide the static  
names of the outer class anyway so its definitely a good practice to  
be specific to avoid accidental name hiding.


>
> An application we should always keep in mind is that here:
>
> builder.{
>   html {
>     body {
>       ol {
>         4.times { li() }
>       }
>     }
>   }
> }
>
> the old syntax required to write builer.li() instead of just li().  
> The new version deosn't mention how to handle that case, but I  
> expect the same way as if li() would be a dircet child of ol. My  
> "adjustment" doesn't change that.

Yeah, that would make sense. Any use of li() in any closure within  
the markup section should generally bind to the builder - so folks  
can use arbitrarily nested blocks/closures inside markup and the  
right things happens; folks can always move code into methods or use  
prefixes if they ever feel restricted by the builder syntax.

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

Reply | Threaded
Open this post in threaded view
|

Re: Closure & Markup name resolution proposal

tugwilson
In reply to this post by jstrachan-3
On 29 Nov 2005, at 08:43, [hidden email] wrote:
> Here's a summary of my thoughts post-the-GroovyOne meeting...
>
> http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name 
> +resolution+proposal
>

As you know I'm not at all keen on this mechanism.

I like and use three and only three key behaviours of the Groovy  
system to do builders.

1/ The compiler allows vanilla identifiers to appear in the code when  
there is no declaration for these identifiers in scope.

2/ The resolution of vanilla  method and property names inside a  
closure is done via the closure's MetaClass

3/ The standard behaviour of a closure's MetaClass is to delegate the  
resolution to the owner

At the moment 1/ is only true for Scripts in classes undefined  
vanilla method names are allowed but undefined property names are  
not. This means I can use all of my builder mechanisms in Scripts but  
only a subset of them in classes.

At the moment 2/ and 3/ are sort of true but the actual mechanism is  
very complicated as we can't tell if access to a name is being made  
from within the  closure body or against its instance (i.e. we can't  
distinguish { println x} from a = {..}; a.x) The new MOP fixes this.

As I understand it in the proposed groovy 1.0 scripts will continue  
to have dynamic behaviour but classes will require all names to be  
resolvable by the compiler (via a reflection mechanism in the  
MetaClass?) The effect of this is that no builder will work in  
classes but all will continue to work in Scripts (there's a problem  
with the behaviour of the Binding in greedily resolving names but  
that problem can be circumvented)

So my proposal is relatively simple:

We already have the compiler working in two modes one for scripts and  
one for classes. We introduce a keyword which tells the compiler  
which mode to work in when compiling a file.

If the standard mode is to statically resolve the names then we say:

package mypakage
dynamic

and the compiler allows undefined names and does not "optimise" the  
selection of the MetaClass to use to resolve names inside a closure.

Scripts are compiled with an implicit "dynamic" directive.

This is important for the future development of builders (or, at  
least, markup builders). It is becoming apparent to me that for a  
class of markup it is preferable to bind an entire class to a builder  
rather than to bind just a closure. This proposal allows classes and  
closures to be bound to builders.


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: Closure & Markup name resolution proposal

Guillaume Laforge
Administrator
In reply to this post by jstrachan-3
Hi all,

On 29/11/05, [hidden email] <[hidden email]> wrote:
> Here's a summary of my thoughts post-the-GroovyOne meeting...
>
> http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name
> +resolution+proposal

Here are some further thoughts on the problem:
http://docs.codehaus.org/display/GroovyJSR/Alternative+solution+to+markup+closures

With explanations of why such a syntax change is not really needed.

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

RE: Closure & Markup name resolution proposal

Dierk König
From a distance the differences in the proposals do not look like
they were unsurmountable.

One question is whether a new language construct would be
optional (?)

If we suppose to have the new construct, the next question is about the
granularity of code that it demarcates (from fine to coarse):
- per name,   e.g. $name
- per line,   e.g. builder.name
- per block,  e.g. builder.{ name }
- per method, e.g. @Dynamic
- per class,  e.g. @Dynamic
- per file,   e.g. @Dynamic
  (reminds me a bit on the Perl 'use warnings' pragma)
- per compile call, e.g. groovyc -w

my 2 cents
Mittie

P.S. I had a short look into the Ruby port of builders.
They require full qualification, i.e. do not allow
vanilla names.


> -----Original Message-----
> From: Guillaume Laforge [mailto:[hidden email]]
> Sent: Mittwoch, 30. November 2005 15:32
> To: [hidden email]
> Subject: Re: [groovy-jsr] Closure & Markup name resolution proposal
>
>
> Hi all,
>
> On 29/11/05, [hidden email] <[hidden email]> wrote:
> > Here's a summary of my thoughts post-the-GroovyOne meeting...
> >
> > http://docs.codehaus.org/display/GroovyJSR/Closure+and+Markup+name
> > +resolution+proposal
>
> Here are some further thoughts on the problem:
> http://docs.codehaus.org/display/GroovyJSR/Alternative+solution+to
> +markup+closures
>
> With explanations of why such a syntax change is not really needed.
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy