Strategies for controling attribute assignment

Steve Holden sholden at holdenweb.com
Tue Oct 2 12:27:02 EDT 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__
on
> >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.

regards
 Steve

--
http://www.holdenweb.com/








More information about the Python-list mailing list