Re: Design for cleaning up Undo for a tree of objects
Re: Design for cleaning up Undo for a tree of objects
- Subject: Re: Design for cleaning up Undo for a tree of objects
- From: Markus Spoettl <email@hidden>
- Date: Wed, 28 Apr 2010 00:41:48 -0400
On Apr 27, 2010, at 9:55 PM, Graham Cox wrote:
> Here's the problem: Any tasks on the undo stack that refer to a particular target must be removed when that target is dealloced. Obviously the clear place to do this is in the -dealloc method. That's fine if the node is still part of the tree at that point, but there's no guarantee that it is. If it is not, it cannot obtain the undo manager needed to remove itself from.
>
> It might seem that when the parent of a node is set to nil (on removal, for example), that could also be the time to clean out any undo tasks pertaining to that object. Unfortunately that isn't the case - the object might be being temporarily removed only to be re-added elsewhere, so any undos relating to it would get cleaned out when they might still be required.
>
> I'm thinking that maybe each node needs a weak ref to the undo manager so that it can find it at dealloc time, but given the potentially thousands of nodes that's an awful lot of extra pointers that are not needed at the moment. It also creates the headache of needing to ensure that the ref is never stale, for example if a node is moved to a tree belonging to another document the ref will need to be updated.
>
> Is there another solution I'm missing?
I'm not sure I follow entirely, I sounds like there's some information missing that explains why the node deletion itself isn't an undoable operation. Which appears to me is causing the problem.
If it was undoable, the node would never get deallocated it would just be stored someplace else (UM). The target weak ref in the undo operations recorded before the node deletion would still be valid, and that's what's important. No?
There are probably good reasons why the node removal isn't undoable and the problem is legitimate, I just can't think of one right now.
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden