Howard~
That makes sense assuming you know how to 'replace B'. That is the
step I am unclear on. I thought that the JVM did not generally allow
you to replace a class with a new definition of it (although I could
be mistaken).
One could insert some amount of magic checking at the beginning of
methods to handle this case:
class A extends JRObject {
JRObject m() {
if(<m was removed or replaced>) {
return addedMethod( <methodID for m()>, null );
}
...
}
}
class B extends A {
@Override JRObject m() {
if(<m was removed or replaced>) {
return addedMethod( <methodID for m()>, null );
}
...
}
}
Matt
On 10/10/07, hlovatt <[EMAIL PROTECTED]> wrote:
>
> @Matt,
>
> Sorry my explanation wasn't that clear, suppose you have:
>
> class A extends JRObject {
> JRObject m() { ... }
> }
>
> class B extends A {
> @Override JRObject m() { ... }
> }
>
> Then you remove B.m, in which case you replace B with:
>
> class B extends A {
> @Override JRObject m() { return super.m(); } // m is declared at
> compile time in super class, A
> }
>
> And if you then remove A.m you replace A with:
>
> class A extends JRObject {
> JRObject m() { return addedMethod( <methodID for m()>, null ); } //
> m isn't in A's superclass
> }
>
> Hope that is a better explanation,
>
> Howard.
>
> On Oct 10, 7:55 am, "Matt Fowles" <[EMAIL PROTECTED]> wrote:
> > Howard~
> >
> > I am not certain I follow your explanation, so I will try to rephrase
> > my question.
> >
> > If a method is known at compile time (and thus called by
> > object.name(...)). How can that method be replaced (or removed) at
> > run time, such that previously compiled code still executes the new
> > version.
> >
> > After thinking about it a bit, I suppose that the compiler can insert
> > a check at the beginning of all the statically compiled methods to
> > check if it has been removed or replaced and delegate to the dynamic
> > dispatch mechanism in that event.
> >
> > Matt
> >
> > On 10/9/07, hlovatt <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > @Matt,
> >
> > > You can redefine compile time methods, e.g. if a method is removed
> > > then provided that the method is in the super class the method body is
> > > replaced with:
> >
> > > return super.name( ... )
> >
> > > A similar technique to the one above is used if the removed method is
> > > in a mix-in. If the removed method isn't in the super class or a mix-
> > > in then:
> >
> > > return addedMethod( methodID, ... )
> >
> > > Howard.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
