Maric Michaud wrote: > Le Mercredi 17 Mai 2006 06:17, [EMAIL PROTECTED] a écrit : > > I want the fact that the fields are > > not strings to be invisible to the client programmers. > You should use properties then.
I started with that idea, using the recipie 20.2 from the cookbook. However, this caused a fair amount of code bloat... Err the way I implemented it did at least. I may be missing a way to regularize the process and make the whole process cleaner too. The problem was that I needed to set the properties for all of the object fields with boilerplate code that looks very much the same. Even if the boilerplate was small, it was still bigger than the one-line descriptor definitions at the bottom of the module. Shrinking the descriptor definitions to a one-liner shrunk the code by a fair bit. There are many classes (100+ when I'm done) and some of them have a fair number of fields (up to 50) and all of them have to have the snazzyStr abilities. Another problem was esthetics; it forces me to place the main class at the bottom of the module after the definition of the supporting classes. Putting the descriptors after the bottom of the module left the important parts at the top where they should be, IMO. I wanted to use supporting classes for the field definitions because it allowed me to use mix-ins. This was the biggest win in the design. Thanks t4 -- http://mail.python.org/mailman/listinfo/python-list
