1 Feb 2005 06:08
Re: Live attributes
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.(Continue reading)
RSS Feed