[groovy-dev] Status

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

[groovy-dev] Status

Guillaume Laforge
Administrator
Hi,

CVS is now fully up-to-date.
The modules are also up-to-date: Guillaume updated GroovySOAP, and Franck restored GroovyJ too.
So we're back on track regarding source control.

It's going to be soon time to do a JSR-06 release (release often mantra), before we release RC-1 with the new MOP.
What do we want to add in this pre-release candidate milestone?

I think it's time we implement the @Property notation change.
If someone fancies adding the date operations, that's the last time to do so before the complete feature freeze of RC-1.
John, you also wanted to introduce some refactorings for preparing the new MOP?

That'd be great if we could release soon the next milestone.
Some bugs have been fixed as well, and Oracle's waiting for their Groovy MBean patches too.

Thoughts?

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

Re: [groovy-dev] Status

Jochen Theodorou
Guillaume Laforge schrieb:

> Hi,
>
> CVS is now fully up-to-date.
> The modules are also up-to-date: Guillaume updated GroovySOAP, and
> Franck restored GroovyJ too.
> So we're back on track regarding source control.
>
> It's going to be soon time to do a JSR-06 release (release often
> mantra), before we release RC-1 with the new MOP.
> What do we want to add in this pre-release candidate milestone?

what about asType, do we want to add that?

> I think it's time we implement the @Property notation change.

yes, I wanted to do that after my class loader changes. They are still
not complete.

> If someone fancies adding the date operations, that's the last time to
> do so before the complete feature freeze of RC-1.
> John, you also wanted to introduce some refactorings for preparing the
> new MOP?

One thing we should do, and this targets the new MOP slightly, is to
remove the invokeMethod code in InvokerHelper. On the user list, there
is a problem because the closure can't call a static method. I found
out, this happens because the decision if a call is to be done static is
made in InvokerHelper, but the closure call only uses the MetaClass...
and I see no reason why this should change. InvokerHelper is a entry
point and should contain as less method invokation logic as possible.

bye blackdrag

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Status

Guillaume Laforge
Administrator
Hi Jochen,

On 6/1/06, Jochen Theodorou <[hidden email]> wrote:
[...]
what about asType, do we want to add that?

That'd be great if we could include that too,  yes.

> I think it's time we implement the @Property notation change.

yes, I wanted to do that after my class loader changes. They are still
not complete.

Okay, perfect.
So JSR-06 should include those class loader changes you've been working on recently, and it will also takes into account the @Property change.

One thing we should do, and this targets the new MOP slightly, is to
remove the invokeMethod code in InvokerHelper. On the user list, there
is a problem because the closure can't call a static method. I found
out, this happens because the decision if a call is to be done static is
made in InvokerHelper, but the closure call only uses the MetaClass...
and I see no reason why this should change. InvokerHelper is a entry
point and should contain as less method invokation logic as possible.

This makes a lot of sense to diminish the role of the InvokerHelper as much as possible.
That should be the business of the MetaClass to make such decisions.

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

Re: [groovy-dev] Status

graemer


On 6/1/06, Guillaume Laforge <[hidden email]> wrote:
Hi Jochen,

On 6/1/06, Jochen Theodorou <[hidden email]> wrote:
[...]

what about asType, do we want to add that?

That'd be great if we could include that too,  yes.

> I think it's time we implement the @Property notation change.

yes, I wanted to do that after my class loader changes. They are still
not complete.

Okay, perfect.
So JSR-06 should include those class loader changes you've been working on recently, and it will also takes into account the @Property change.

One thing we should do, and this targets the new MOP slightly, is to
remove the invokeMethod code in InvokerHelper. On the user list, there
is a problem because the closure can't call a static method. I found
out, this happens because the decision if a call is to be done static is
made in InvokerHelper, but the closure call only uses the MetaClass...
and I see no reason why this should change. InvokerHelper is a entry
point and should contain as less method invokation logic as possible.

This makes a lot of sense to diminish the role of the InvokerHelper as much as possible.
That should be the business of the MetaClass to make such decisions.


Hmm yes but at the same time InvokerHelper is very useful when you're working with the API at my level (ie Meta stuff). The reason is sometimes the object is a GroovyObject and sometimes it is not.

By doing

InvokeHelper.invokeMethod(obj,'methodName',args)

It encapsulates the logic necessary to retrieve the MetaClass (whether from the registry or the Groovy object property) and call said method when invoking a dynamic method from Java.

Otherwise we would have to write helpers ourselves to perform this task.

I agree with diminishing its role internally within the Groovy core, but removing this method entirely is not helpful for users of the API

Graeme
 

--
Guillaume Laforge
Groovy Project Manager
<a href="http://glaforge.free.fr/blog/groovy" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://glaforge.free.fr/blog/groovy

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Status

Jochen Theodorou
Graeme Rocher schrieb:
[...]
> Hmm yes but at the same time InvokerHelper is very useful when you're
> working with the API at my level (ie Meta stuff). The reason is
> sometimes the object is a GroovyObject and sometimes it is not.

sorry, you misunderstood me, I still want to have the method, but I
don't want to have the logic in there. At last not this much. Many of
the Invoker methods are mere stubs, and this should be the same for
invokeMethod in InvokerHelper


bye blackdrag

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Status

Guillaume Laforge
Administrator

On 6/1/06, Jochen Theodorou <[hidden email]> wrote:
Graeme Rocher schrieb:
[...]
> Hmm yes but at the same time InvokerHelper is very useful when you're
> working with the API at my level (ie Meta stuff). The reason is
> sometimes the object is a GroovyObject and sometimes it is not.

sorry, you misunderstood me, I still want to have the method, but I
don't want to have the logic in there. At last not this much. Many of
the Invoker methods are mere stubs, and this should be the same for
invokeMethod in InvokerHelper


Yes, there is some logic in the InvokerHelper which shouldn't be there and which should be the job of the MetaClass.
So it's more a question of rewiring things rather than actually removing this handy method.
Don't worry Graeme ;-)
But thanks for reminding us about that!



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

Re: [groovy-dev] Status

tugwilson
In reply to this post by Guillaume Laforge

On 1 Jun 2006, at 09:47, Guillaume Laforge wrote:

>
> This makes a lot of sense to diminish the role of the InvokerHelper  
> as much as possible.
> That should be the business of the MetaClass to make such decisions.


I quite agree - the long term aim is to push pretty much everything  
into MetaClasses. In the end I would hope that there would never be a  
need to use instanceof in the runtime system.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Status

tugwilson
In reply to this post by graemer

On 1 Jun 2006, at 09:58, Graeme Rocher wrote:

> Hmm yes but at the same time InvokerHelper is very useful when  
> you're working with the API at my level (ie Meta stuff). The reason  
> is sometimes the object is a GroovyObject and sometimes it is not.
>
> By doing
>
> InvokeHelper.invokeMethod(obj,'methodName',args)
>
> It encapsulates the logic necessary to retrieve the MetaClass  
> (whether from the registry or the Groovy object property) and call  
> said method when invoking a dynamic method from Java.
>
> Otherwise we would have to write helpers ourselves to perform this  
> task.
>
> I agree with diminishing its role internally within the Groovy  
> core, but removing this method entirely is not helpful for users of  
> the API


I don't think it's being suggested that we remove the method or  
change its functionality. The problem at the moment is that there's a  
bunch of functionality that is implemented between the call of  
invokeMethod and the call on the MetaClass. A lot of this is special  
case code which depends on the type of 'obj'. This is undesirable for  
several reasons. Firstly it means you have to look all over the place  
to understand the magic properties of an object. If the magic was in  
the MetaClass for that object then you would be able to understand  
the behaviour by looking in only one place. Secondly it has a large  
impact on performance. The path through invokeMehtod is one of the  
critic al paths in the run time system. You really don't want to have  
a bunch of "instanceof'as and  "isAssignableTo"s in that path. The  
MetaClass knows all about the class (e.g. it knows if it's a closure  
or not) so the whole execution path can be made simpler and quicker.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email