Strategies for controling attribute assignment
sholden at holdenweb.com
Tue Oct 2 18:27:02 CEST 2001
"Dale Strickland-Clark" <dale at riverhall.NOSPAMco.uk> wrote ...
> "Steve Holden" <sholden at holdenweb.com> wrote:
[ ... ]
> >1. Use names with a special prefix for the database fields, then you can
> >just test the attribute name using beginswith() or similar to determine
> >whether it's a database filed.
> >2. Have objects store database fields inside another object (such as a
> >DatabaseTuple), so instead of assigning
> > object.dbfield = value
> >you assign
> > object.db.field = value
> >This localises the database fields and means you don't need __setattr__
> >the object itself.
[ ... ]
> Thanks for sticking with this so far.
> The problem isn't with handling the database assignments. It's the
> fact that all instance assignments (self.anything) has to go through
> the same code. This is such an ugly overhead.
> Throughout the class, there are dozens of uses of instance variables
> which are forced through this code. I don't want to know about them.
> I guess I'd like to explicitly declare which attributes are part of
> the public face of the class and which are not.
> I assume my approach is as good as any.
Well, the advantage of centralizing the database fields as attributes of a
contained object is that you then only need to monitor bindingd to the
attributes of that object, so the containing object wouldn't need a
__setattr__() implementation. If you can't do that then I guess you're stucj
with something similar to your current approach.
More information about the Python-list