[TransWarp] multiple class advisors

[Phillip J. Eby]

At 09:59 PM 10/2/03 +0200, Radek Kanovsky wrote:
>Hi,
>
>I have a problem with my simple advisor. It shadows protocols.advise
>when used both together. Additionally it is order dependent. When I swap
>advisors order (myadvisor call is before protocols.advise call), everything
>works OK.

Advisors are order dependent by definition.  Note that each callback is 
expected to return the new "value" of the class, which is then supplied to 
the next callback.  That is, there is a chain of advisors.  So, what you 
are seeing is "as designed".  The "shadowing" you see is that the advise() 
callback is making declarations about the *original* class, not your new 
class.  Since your new class does not inherit from the originally created 
class, it does not inherit any of the advise() definitions.  Does that make 
sense?


>Can we extend somehow class in class advisors? I am not sure
>if extending class with binding in advisor is correct.

You can, but if you want to interoperate with protocols.advise it would 
probably be best to either modify it in-place (e.g. klass._myadvisor = 
binding.Make(a)) or create a subclass of the original class.  If the 
binding needs to be accessible in class-level registries (e.g. 
__class_descriptors__), then you would need to update __class_descriptors__ 
as well.

Probably the *simplest* thing to do, however, would not be to use class 
advisors.  Instead of using a callback, just modify the locals dictionary 
of the class namespace you're called in.  That is, use the 'getFrameInfo()' 
function to get a hold of the locals dictionary, and stick the binding in 
that.  Then, it will be present in the class dictionary when the class is 
created; it'll be as though the user had directly defined it in the class 
body.

Of course, this will only work if your advisor doesn't need access to 
anything in the class body that comes after it's called.