Paris write-up

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

Paris write-up

Sam Pullara-2
I'd be pretty disappointed if "use" didn't still work similarly to  
the way it does now.  These examples I think are typical of what  
people would do:

http://groovy.codehaus.org/Groovy+Categories

Sam


Reply | Threaded
Open this post in threaded view
|

RE: Paris write-up

Dierk König
Hi Sam,

this will still work.

you can still do

use(MyClass.class){}

what you cannot do is

def x = MyClass.class
use(x) {}

cheers
Mittie

> -----Original Message-----
> From: Sam Pullara [mailto:[hidden email]]
> Sent: Dienstag, 29. November 2005 18:53
> To: [hidden email]
> Subject: [groovy-jsr] Paris write-up
>
>
> I'd be pretty disappointed if "use" didn't still work similarly to  
> the way it does now.  These examples I think are typical of what  
> people would do:
>
> http://groovy.codehaus.org/Groovy+Categories
>
> Sam
>
Reply | Threaded
Open this post in threaded view
|

Re: Paris write-up

jstrachan
On 29 Nov 2005, at 19:47, Dierk Koenig wrote:

> Hi Sam,
>
> this will still work.
>
> you can still do
>
> use(MyClass.class){}
>
> what you cannot do is
>
> def x = MyClass.class
> use(x) {}

Yeah - we're just trying (for 1.0 at least) to restrict the use()  
statement to be given a statically known class expression (like  
import but without the wildcards) so we can know at compile time how  
the ASTs all change when a use() is introduced so we can give better  
compile errors and generate better bytecode.

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

Reply | Threaded
Open this post in threaded view
|

Re: Paris write-up

tugwilson
In reply to this post by Dierk König

On 29 Nov 2005, at 19:47, Dierk Koenig wrote:

> Hi Sam,
>
> this will still work.
>
> you can still do
>
> use(MyClass.class){}
>
> what you cannot do is
>
> def x = MyClass.class
> use(x) {}


But I thought that the Paris meeting decided that the effect would be  
in restricted to the lexical scope. The current implementation  
applies to any method called from the use closure in the current thread.

Was this not the case?


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


Reply | Threaded
Open this post in threaded view
|

Re: Paris write-up

Jochen Theodorou
In reply to this post by jstrachan
James Strachan schrieb:

> On 29 Nov 2005, at 19:47, Dierk Koenig wrote:
>
>> Hi Sam,
>>
>> this will still work.
>>
>> you can still do
>>
>> use(MyClass.class){}
>>
>> what you cannot do is
>>
>> def x = MyClass.class
>> use(x) {}
>
>
> Yeah - we're just trying (for 1.0 at least) to restrict the use()  
> statement to be given a statically known class expression (like  import
> but without the wildcards) so we can know at compile time how  the ASTs
> all change when a use() is introduced so we can give better  compile
> errors and generate better bytecode.

James, I think Sam was speaking about the GroovyCategorySupport, the
thread local addition of methods not only to the lexical scope. the
writeups are showing an limitation of use to the lexical block that
follows the "use". If we do so, the "new" use will be different from the
"old" one, because the old use affected not only method calls in the
lexical block.

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

RE: Paris write-up

Dierk König
In reply to this post by tugwilson
Yes, that's been said.

I must confess it irritates me. For most cases of 'use'
that I can currently think of, it makes it makes it very
awkward to use.
Think about ServletCategory and related usages.

We would need a 'use' block whereever a newly introduced
name is used. So possibly again in the method that's called
from inside the closure.

cheers
Mittie

> -----Original Message-----
> From: John Wilson [mailto:[hidden email]]
> Sent: Dienstag, 29. November 2005 21:15
> To: [hidden email]
> Subject: Re: [groovy-jsr] Paris write-up
>
>
>
> On 29 Nov 2005, at 19:47, Dierk Koenig wrote:
>
> > Hi Sam,
> >
> > this will still work.
> >
> > you can still do
> >
> > use(MyClass.class){}
> >
> > what you cannot do is
> >
> > def x = MyClass.class
> > use(x) {}
>
>
> But I thought that the Paris meeting decided that the effect would be  
> in restricted to the lexical scope. The current implementation  
> applies to any method called from the use closure in the current thread.
>
> Was this not the case?
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
Reply | Threaded
Open this post in threaded view
|

Re: Paris write-up

tugwilson

On 30 Nov 2005, at 07:46, Dierk Koenig wrote:

> Yes, that's been said.
>
> I must confess it irritates me. For most cases of 'use'
> that I can currently think of, it makes it makes it very
> awkward to use.
> Think about ServletCategory and related usages.
>
> We would need a 'use' block whereever a newly introduced
> name is used. So possibly again in the method that's called
> from inside the closure.


Can we separate are concerns here?

Firstly we have to be clear what came out of the Paris meeting -

James proposed to replace the current "use" mechanism with a more  
limited one. The main motivation seemed to be to allow the compiler  
to detect typos and the IDE to do code completion. In order to do  
this the compiler and IDE needed to know what names were introduced  
by the use clause. He therefor proposed to replace the use method  
(which is defined in DGM as I'm sure you know) with a language  
construct (name to be decided. For the purpose of this discussion  
let's call it "introduce") the introduce construct would apply to a  
block not a closure. It would take literal classes not parameters and  
there would be some mechanism (yet to be defined) for the compiler to  
determine what names where introduced into the local scope and added  
to objects used in that scope. There would also be a way (yet to be  
defined) for one of the literal classes to say that an infinite  
number of names would be introduced in which case the compiler would  
allow any name to be used in the block. There was a little bit of  
discussion on how this might be done and some sort of local MetaClass  
proxy was suggested for resolving local names (i.e. names of the form  
this.name or name rather then x.name) No suggestion was made about  
how we would deal with names of the form x.name. I suggested that if  
we had this construct then we should have a way of applying the  
introduce mechanism to whole function modules and entire classes this  
was considered out of scope for Groovy 1.0.

Now what does this construct introduce

1/ the ability to add and change functions and properties on "this"  
and on other objects only in the lexical scope.

2/ the ability to get the compiler to relax it's draconian parse  
rules to allow names which appear to be undefined to appear as local  
names.

What does it remove

1/ the mechanism which Sam implemented and documented.

If anybody who was at the Paris meeting disagrees with any of the  
above please say so load and clear because the rest of this  
discussion will only make sense if we agree on what was decided.

I will post another message on this thread will my own views on the  
meeting and on this point.



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


Reply | Threaded
Open this post in threaded view
|

Re: Paris write-up

jstrachan
In reply to this post by Dierk König
Could we step back a little and explain the use case (pardon the pun :)

We're defining a closure, then after the closure is created we're  
then adding methods to the classes used in the closure.


I'm just wondering; after a quick scan of the Groovy Categories page;  
is there any reason why the use statement can't be right at the top  
of the file like imports are. e.g. use kinda means 'I'd like to add  
some useful methods to some types in this file or lexical block'.  
Would that do the trick?

All the examples on the Groovy Categories page look totally fine to  
me - apart from the GroovyServlet example which I don't quite grok.  
In that example couldn't we change

GroovyCategorySupport.use(ServletCategory.class, closure);

to be

use ServletCategory

(at the top of the file/script)



On 30 Nov 2005, at 07:46, Dierk Koenig wrote:

> Yes, that's been said.
>
> I must confess it irritates me. For most cases of 'use'
> that I can currently think of, it makes it makes it very
> awkward to use.
> Think about ServletCategory and related usages.
>
> We would need a 'use' block whereever a newly introduced
> name is used. So possibly again in the method that's called
> from inside the closure.
>
> cheers
> Mittie
>
>> -----Original Message-----
>> From: John Wilson [mailto:[hidden email]]
>> Sent: Dienstag, 29. November 2005 21:15
>> To: [hidden email]
>> Subject: Re: [groovy-jsr] Paris write-up
>>
>>
>>
>> On 29 Nov 2005, at 19:47, Dierk Koenig wrote:
>>
>>> Hi Sam,
>>>
>>> this will still work.
>>>
>>> you can still do
>>>
>>> use(MyClass.class){}
>>>
>>> what you cannot do is
>>>
>>> def x = MyClass.class
>>> use(x) {}
>>
>>
>> But I thought that the Paris meeting decided that the effect would be
>> in restricted to the lexical scope. The current implementation
>> applies to any method called from the use closure in the current  
>> thread.
>>
>> Was this not the case?
>>
>>
>> John Wilson
>> The Wilson Partnership
>> http://www.wilson.co.uk
>>


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

Reply | Threaded
Open this post in threaded view
|

RE: Paris write-up

Dierk König
In reply to this post by Dierk König
I expect that for most usages, the file-wide 'use'
directive will be used...

cheers
Mittie

> -----Original Message-----
> From: Dierk Koenig [mailto:[hidden email]]
> Sent: Mittwoch, 30. November 2005 8:46
> To: [hidden email]
> Subject: RE: [groovy-jsr] Paris write-up
>
>
> Yes, that's been said.
>
> I must confess it irritates me. For most cases of 'use'
> that I can currently think of, it makes it makes it very
> awkward to use.
> Think about ServletCategory and related usages.
>
> We would need a 'use' block whereever a newly introduced
> name is used. So possibly again in the method that's called
> from inside the closure.
>
> cheers
> Mittie
>
> > -----Original Message-----
> > From: John Wilson [mailto:[hidden email]]
> > Sent: Dienstag, 29. November 2005 21:15
> > To: [hidden email]
> > Subject: Re: [groovy-jsr] Paris write-up
> >
> >
> >
> > On 29 Nov 2005, at 19:47, Dierk Koenig wrote:
> >
> > > Hi Sam,
> > >
> > > this will still work.
> > >
> > > you can still do
> > >
> > > use(MyClass.class){}
> > >
> > > what you cannot do is
> > >
> > > def x = MyClass.class
> > > use(x) {}
> >
> >
> > But I thought that the Paris meeting decided that the effect would be
> > in restricted to the lexical scope. The current implementation
> > applies to any method called from the use closure in the current thread.
> >
> > Was this not the case?
> >
> >
> > John Wilson
> > The Wilson Partnership
> > http://www.wilson.co.uk
> >

Reply | Threaded
Open this post in threaded view
|

Re: Paris write-up

tugwilson
In reply to this post by jstrachan

On 30 Nov 2005, at 08:30, James Strachan wrote:

>
> We're defining a closure, then after the closure is created we're  
> then adding methods to the classes used in the closure.

and in any method called by the closure.


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


123