Re: A Nib Question: Multiple Instantiations of Views
Re: A Nib Question: Multiple Instantiations of Views
- Subject: Re: A Nib Question: Multiple Instantiations of Views
- From: Greg Titus <email@hidden>
- Date: Fri, 5 Apr 2002 14:40:01 -0800
On Friday, April 5, 2002, at 02:02 PM, David Remahl wrote:
What is the justification for not having NSView conform to NSCopying?
This
is an often requested function, and I can't see why it couldn't be
implemented...
Since loading the view from NIB is better in a vast majority of cases,
and
Apple wants to press on developers slightly to go the recommended way,
perhaps?
Well, I was mainly interested in _why_ that was the recommended way. I'm
sure there is a very good explanation, but I don't see it. Why is it
better
to cause disk (or at least disk cache) access when copying stuff in
memory
could have been enough?
Well, in this case, it's better because the nib route hooks up outlet
and target/action connections. One of the issues in the original
question, for instance, was to change the text in a text field buried in
the view hierarchy somewhere. If you did a copy in code, you'd have to
walk down the copied view hierarchy explicitly to find the right view,
which is error-prone, and leads to code which is quite fragile. (I.e. if
he later decided to add another text field subview you'd have to go back
and look at this code and change it appropriately to set both, or
determine between them somehow, or whatever.)
This is a general problem with copying complex object subgraphs. If you
implemented -mutableCopy on a view, you'd certainly copy any attributes,
tell the subviews to copy themselves, et cetera. But would you copy
delegates? Would you copy targets and actions? Maybe you'd complicate
things so that you'd duplicate targets/actions/outlets to point to new
objects if they pointed to other subviews in the hierarchy that you are
currently copying, and leave them as pointers to the original objects
otherwise, but are you sure that that is what the user intends all the
time? And I sure wouldn't want to write that code. :-)
When you think about it that way, it suddenly seems (at least to me)
like deserializing frozen views from a nib (from data which is certain
to be in disk cache after the first time the nib is loaded), is probably
more efficient than doing both steps: serializing the in-memory views to
determine which connect to others in the subtree and which don't, then
deserializing them all back again as copies.
--Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.