Making DGM extensible / Extensible MetaClass

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

Re: Making DGM extensible / Extensible MetaClass

graemer
On 9/26/06, Jochen Theodorou <[hidden email]> wrote:

> sorry, posted only to the jsr list
>
> Graeme Rocher schrieb:
> > On 9/26/06, Jochen Theodorou <[hidden email]> wrote:
> >> I think there are some small points I currently do not understand.
> >>
> >> First. We are talking about optimization to the method selection. What
> >> is the matter of redoing that? We haven't have that now, I maybe we will
> >> be able to use parts of it without bytecode production. And even then..
> >> we can recompile. What is the problem? sure, it is costly, but normally
> >> such things are not done in runtime critical parts. Maybe it is possible
> >> to chain the method selections...
> >>
> >> The alternative is setting a custome MetaClass... but doesn't that
> >> approach have the same problems? And isn't it the same vor Categories?
> >> Regardless the thread visibility, we do add methods.
> >
> > So you're suggesting my first proposal is a possibility?
>
> we could have multithreaded ategories... The approach with closures is..
>
> object.metaClass.addMethod("foo") { println "hi" }
>
> we could something like that for closures. This actually adds 2 methods,
> foo() and foo(Object). In fact I used that already in a modified version
> some time ago.
>
> [...]
> > at the moment with custom
> > MetaClasses as a developer you have to think about these things. You
> > have to think "what happens if the method exists?" or "what if its
> > overloaded?".
> >
> > This only further increases the point on entry. If, however, there was
> > something built into Groovy that would throw appropriate errors with
> > good errror messages if you tried to replace an existing method or
> > causes overloading issues like your example above I think thats
> > perfectly acceptable and in fact a good thing.
>
> yes, that is what I want to do. It is not much of a problem to find the
> problematic cases I think.
>
> ah.. but one moire thing... why the hell new
> GroovyClassLoader(Foo.class) ???

I think it was so you could provide categories to the class loader. So
like adding a modifed DGM or something

Graeme

>
> bye blackdrag
>
> --
> Jochen Theodorou
> Groovy Tech Lead
> http://blackdragsview.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Making DGM extensible / Extensible MetaClass

Victor Volle
Hi,

can anyone tell what's the current state of this issue?

Victor

On 9/26/06, Graeme Rocher <[hidden email]> wrote:

> On 9/26/06, Jochen Theodorou <[hidden email]> wrote:
> > sorry, posted only to the jsr list
> >
> > Graeme Rocher schrieb:
> > > On 9/26/06, Jochen Theodorou <[hidden email]> wrote:
> > >> I think there are some small points I currently do not understand.
> > >>
> > >> First. We are talking about optimization to the method selection. What
> > >> is the matter of redoing that? We haven't have that now, I maybe we will
> > >> be able to use parts of it without bytecode production. And even then..
> > >> we can recompile. What is the problem? sure, it is costly, but normally
> > >> such things are not done in runtime critical parts. Maybe it is possible
> > >> to chain the method selections...
> > >>
> > >> The alternative is setting a custome MetaClass... but doesn't that
> > >> approach have the same problems? And isn't it the same vor Categories?
> > >> Regardless the thread visibility, we do add methods.
> > >
> > > So you're suggesting my first proposal is a possibility?
> >
> > we could have multithreaded ategories... The approach with closures is..
> >
> > object.metaClass.addMethod("foo") { println "hi" }
> >
> > we could something like that for closures. This actually adds 2 methods,
> > foo() and foo(Object). In fact I used that already in a modified version
> > some time ago.
> >
> > [...]
> > > at the moment with custom
> > > MetaClasses as a developer you have to think about these things. You
> > > have to think "what happens if the method exists?" or "what if its
> > > overloaded?".
> > >
> > > This only further increases the point on entry. If, however, there was
> > > something built into Groovy that would throw appropriate errors with
> > > good errror messages if you tried to replace an existing method or
> > > causes overloading issues like your example above I think thats
> > > perfectly acceptable and in fact a good thing.
> >
> > yes, that is what I want to do. It is not much of a problem to find the
> > problematic cases I think.
> >
> > ah.. but one moire thing... why the hell new
> > GroovyClassLoader(Foo.class) ???
>
> I think it was so you could provide categories to the class loader. So
> like adding a modifed DGM or something
>
> Graeme

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

    http://xircles.codehaus.org/manage_email

12