[PEAK] Live attributes

[Phillip J. Eby]

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: 
>http://blog.ianbicking.org/descriptor-nit.html
>
>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.
>
>Any thoughts?

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.