[TransWarp] multiple class advisors
Phillip J. Eby
pje at telecommunity.com
Thu Oct 2 16:15:38 EDT 2003
At 09:59 PM 10/2/03 +0200, Radek Kanovsky wrote:
>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
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
>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__
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
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.
More information about the PEAK