Strategies for controling attribute assignment

[Dale Strickland-Clark]

"Steve Holden" <sholden at holdenweb.com> wrote:

>I think so. For a start it appears to mean that we can forget all about
>class attributes ...
>
>I'm not sure why using a dictionary appears so evil to you, given that you
>seem to need the dictionary for field validation anyway. Two possible
>simplistic alternatives suggest themselves immediately, which might be
>enough to loosen your thinking and give you a better solution for your
>needs.
>
>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.
>
>Of course there may well be valid reasons why neither of these approaches is
>satisfactory. Explain why not, and others might well have better
>suggestions.
>
>regards
> Steve

Steve,

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.

Thanks.
--
Dale Strickland-Clark
Riverhall Systems Ltd