2008/8/21 Jerome Laheurte <[EMAIL PROTECTED]>:
> So why not use the standard library 'copy' module, which does just
> that, AFAIK ?

Yeah, that was one option crossing my mind. Then we can implement
__copy__ and __deepcopy__ as needed.

> Mmmh, I'm not keen on adding an extra keyword argument to a special
> method used by the standard library (I think __getstate__ and
> __setstate__ are used by both copy and pickle). There's something that
> bugs me there: a method that is supposed to return a state,
> independent from any application-specific class, actually returns
> something that include instances of domain objects. I think that
> instead of including a list of children copies, it should include a
> list of children states. As I said earlier, this will need special
> handling for deletion/creation of children, but I think it's worth it.

Well, __getstate__/__setstate__ are historical accidents. I think I
used the pickle module when I started with TC. We can rename these
methods any way we want.

Although I agree with your dislike of a method called getstate that
returns a mixture of state and objects, I am not sure that that is the
root issue. I've been thinking for a while now that the whole state
copying is a bad thing. We need to copy the state because of the edit
dialogs. With the current edit dialogs, we don't know what the user is
going to change and she may basically change any property of an
object, including the addition or removal of a whole tree of sub
objects. That's why we need to copy the whole state of domain objects.
Now, if the user cannot edit the whole state of an object, but only
one property at a time, we don't need to copy state. For example, the
change task priority commands don't save state, do and undo are really
each other's inverse operation (as do and undo are meant to be :-):

class ChangePriorityCommand(base.BaseCommand):
    def changePriorities(self, delta):
        for task in self.items:
            task.setPriority(task.priority() + delta)

    def do_command(self):
        super(ChangePriorityCommand, self).do_command()
        self.changePriorities(self.delta)

    def undo_command(self):
        self.changePriorities(-self.delta)
        super(ChangePriorityCommand, self).undo_command()

    def redo_command(self):
        super(ChangePriorityCommand, self).redo_command()
        self.changePriorities(self.delta)


If we make domain objects editable without dialogs (double clicking
would open an floating AUI managed frame showing one task, for
example, and each change would be effective immediately) this whole
issue disappears...

However, there's another however: the dialog-less interface is of
course too much work to fix this bug, so (stop dreaming Frank) we
still need to fix this bug now. I don't think we should worry too much
about getstate not being totally consistent, though.

Cheers, Frank

Reply via email to