From: "Avi Bryant" <avi at beta4.com>
> ducasse wrote:
>
> > so this is perfect.
> > how do you do that? you check at unload time if you should reinstall a
> > method. What's happen if I have three methods
> >
> > P1>>C>>m
> > P2>>C>>m
> > P3>>C>>m
> > with this load order
> >
> > Then unload P3 do I get P2?
> >
> > Then can I unload p2? i guess yes if there is no dependencies between
> > p2 and p3, so I should get p3>>C>>m
>
>
> If you unload P3 you would get P2.
> If you then unload P2 you would get P1.
>
> Or,
>
> If you unload P2 first you would remain at P3.
>
> But,
>
> If you then unload P3, you would get P2, which is a bug.

Stephane asked exactly the right question.

The way to get the right behavior is to associate with each
behavior/selector-pair for which a method definition exists in more than one
loaded package, a stack of method definitions.

The method of the definition that is on the top of the stack is the only one
that can be executed.

The other method definitions in the stack can still be viewed in
package-aware browsers and edited and saved into their respective packages.

The order of the methods in the stacks is a reflection of the "load order"
of their packages. The version of the package that is most recent in the
load order is on top. No exceptions to this rule are allowed.

By default, the load order of the packages is the order in which they were
loaded ;-) (this implies that package loads must be serialized).

But there is no objection to allowing the load order of already loaded
packages to be changed afterwards. Such a load order change may result in
different methods being installed in the classes' method dictionaries.

It's really quite a simple and elegant design and very effective.

Now go and implement this quickly before I change my mind and patent it ;-).

Cheers,

Peter van Rooijen
Amsterdam

> P2
> doesn't/can't "unload" the shadowed version (which only exists in the
> .changes file) and so that stays in the stack.