On 06/02/2011, at 11:37 AM, John Bartleson wrote: > A lot of the confusion comes about because of poor documentation. Apple's > "Introduction to Undo > Architecture" doesn't clearly explain that the sequence beginning with > prepareWithInvocationTarget: > results in NSUndoManager effectively taking ownership of n00b's method and > its arguments. (Please > forgive my inexactness in terminology here, Graham, NSUndoManager messes with > my head!)
That's a big part of the problem here - you are assuming NSUndoManager is somehow infinitely more complicated than every other class. It's not. It follows the standard rules at all times. If it helps, you can think of it much like a collection - all it does is to accumulate tasks on a pair of stacks. As with any collection class, it owns its contents. You're also confusing yourself with respect to an object "taking ownership of [my] method and its arguments". A method isn't an object, so there is no ownership to be concerned about (except the implicit 'ownership' in a more abstract sense that a class has over its own methods, but that isn't a memory management concern for the programmer.). An NSInvocation turns a method into an object, but it isn't the original method - it's just a reference to it. This requires no new thinking. When an NSInvocation object is made, it is owned by whoever alloc'ed it. In this case that's NSUndoManager. Not you. End of story. Just because it embodies a reference to something you own (but you don't - methods are not owned), doesn't make it your responsibility any more than any other similar case. Invocations are not special cases, so stop trying to make that assumption fit. > That's a minor problem, though, relative to the next one: the documentation > says "An NSUndoManager object > does not retain the targets of undo operations." While technically true (the > target is the object > containing the method calling prepareWithInvocationTarget:, not the method to > be invoked), n00b will > invariably read this sentence to mean that NSUndoManager does not retain > (take ownership of) the arguments > to the method to be invoked. A noob might if they were not reading carefully. The documentation does not state that, and does not imply that. If a reader takes away that impression, they have not read it carefully. I don't think the fault can be laid at the blame of the documentation writer there. The onus is on the reader to read and understand what is actually written and stated, not what they think it does. > Let me make one final point: this topic would have never come up if I had had > a tool that would let me track the > lifetime of an object. Very hypothetically, suppose I could write my code, > execute it, and then, in the debugger or > whatever, could issue a command like "Track someObjectName". During > execution, I'd see the following: I believe the 'Leaks' tool will give you exactly that. Or if not leaks then one of the others, but my unfamiliarity with it makes it difficult to remember which one it is. I used it once I think._______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
