[PEAK] Live attributes
Phillip J. Eby
pje at telecommunity.com
Tue Feb 1 00:08:16 EST 2005
At 12:42 PM 1/31/05 -0600, Ian Bicking wrote:
>A while ago I posted about a problem with descriptors not knowing what
>class or name they were bound to:
>Phillip, you noted that PEAK had something like this, IActiveDescriptor
>and activateInClass. Anyway, I'm finally getting around to refactoring
>SQLObject to do this, and I don't want to just invent my own names, and
>since I find this basic pattern really useful it would be nice to have
>some cross-library convention on how to do this. OTOH, I don't want to
>add a PyProtocols/adaptation requirement to SQLObject for this small
>feature. Somehow activateInClass doesn't seem magic enough without
>adaptation, though at the same time maybe it doesn't matter; is there
>really likely to be a name conflict. OTOH, without adaptation it's
>only outwardly similar to PEAK, it's certainly not a drop-in replacement.
Well, I could change to a generic function and just look for the attribute.
One caveat: be aware that a descriptor can be placed in more than one
class. Part of what PEAK's descriptors do is immediately replace
themselves with another object that knows the attribute name, so that if
the descriptor is placed in multiple classes, they don't all think they're
in the same class with the same name.
I don't know that there's that much utility to a cross-library version of
this; if somebody needs to use both SQLObject and PEAK they can always
register an adapter from the SQLObject types to PEAK's interface(s), and
then use PEAK's binding.activateClass() function to activate them.
More information about the PEAK