Sorry, I was busy and couldn't reply. Now it's time to finish this
thread.
Graham Cox said:
In the middle step, why should YOU worry about whether the undo
manager has retained 'descriptorsCopy'? It's not your responsibility
how that object works. It might have retained the object, copied it,
turned it into something completely different, or buried it in soft
peat for three months. Not your concern. All you know is, following
that line, you have no further interest in the object, so you
release it.
Thanks for this statement of a generally-applicable principle. If
we're talking about passing
an object to, say, a collection, then it's easy to see when the
collection has taken ownership
(put a leash on the dog) and we can release our interest. However,
when learning NSUndoManager
the n00b probably won't see that NSUndoManager takes ownership of the
method invocation
following prepareWithInvocationTarget:self. Indeed, it looks to n00b
as if he himself is fully
responsible for the undo method and its arguments. After all, he sees
it as his code rather
than NSUndoManager's.
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 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.
N00b's first impression will be incorrect. As Graham says "The object
returned by the undo manager turns
that into an NSInvocation internally, which almost certainly does
retain its arguments."
Looks to me like the person writing the documentation was too close to
the implementation, and wasn't
able to put him/herself in n00b's shoes. This is a common problem in
technical docs.
I will use the "Did this document help you?" response to the
NSUndoManager web docs and see if we can
get it updated to avoid the problems described above.
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:
(timestamp) (code location) someObjectName: allocated
(timestamp) (code location) someObjectName: init
(timestamp) (code location) someObjectName: retained
(timestamp) (code location) someObjectName: released
(timestamp) (code location) someObjectName: released
(timestamp) (code location) someObjectName: dealloc
II realize that a tool like this appears to be against your stated
philosophy, Graham, but it sure would
have saved me and the Cocoa list a lot of time and frustration.
_______________________________________________
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
