Michel Pelletier writes:
It's not too bad, although you are correct that allways get more complex and never less. We have generally been able to avoid incredibly complex setstates because we try to not evolve an object to incredibly, as opposed to engineering a new kind of object that abstracts out or delegates or whatever.
I don't think we can guarantee that on our project. Right now we're looking at various object databases, most notably POET, Versant, and ZODB, to serve as the primary data store for our project. We're storing business objects, and therefore we can't predict how the objects will need to evolve in future. For example, we started out some months ago saying that .cost is just a numeric value or None. Now we've done some more requirements based on experience gained since then, and our cost requirements are now laid out in a 10-page document. Requiring that new classes be created to handle such changes means we'll end up with a *lot* of baggage to drag around,
Also, if you just want to add an attribute you can add a shared instance attribute to the class definition. We do this alot to avoid changing
Jim mentioned that in conversation; it doesn't work if the instance attribute is something mutable like a list that gets appended to, so it's not a fully general solution.
Which makes me thing you would want to do something like this analgously to UNIX 'single user mode', ie, shut down your site, and run a single thread to execute this method of yours (immagine, for example, what
Very probably this will be necessary. But my point is that there's no way to re-use the traversal logic that lives in pack(), so you have to re-impelement the traversal logic. -- A.M. Kuchling http://starship.python.net/crew/amk/ K is for KENGHIS KHAN. *He* was a very *nice* person. History has no record of him. There is a moral in that, somewhere. -- Harlan Ellison, "From A to Z in the Chocolate Alphabet"