Re: Copy and release
Re: Copy and release
- Subject: Re: Copy and release
- From: Paul Sargent <email@hidden>
- Date: Fri, 22 Oct 2004 17:03:12 +0100
Wade Tregaskis wrote:
A question I've had is when a container is said to be immutable, is
it still fair game to change the contents of the objects that are
contained?
For example: An NSArray containing NSMutableString objects, or an
NSData object. Can you / Should you change the contents of the
NSMutableStrings in the NSArray or the Memory block pointed to by the
NSData?
Should items contained in immultable container classes be considered
immutable?
Not necessarily. Your design should specify if this is the case,
otherwise it's most likely assumed that the immutability attribute
applies only to the container, not it's contents. This is consistent
with the rest of Foundation's container behaviour, and that of other
common containers such as found in the STL (where everything, most
notably copies, are shallow in so far as containers holding pointers
are concerned).
Sounds like both you and Nicko confirm my instincts. I've alwas thought
that the immutable moniker is only for the container class itself, and
not the objects it contains, despite my wording of the question.
P.S. Sorry for taking this further off-topic. As far as the OP goes,
the main effeciency point I've seen when dealing with mutable Vs.
immutable is that a copy of an immutable object can just be a
reference to the same object, but a mutable copy needs to be a full
copy. Things is, why do you need a copy? If it's to change it, then
it needs to be mutable, and you need a full copy. If it's just to
call it by a different name, then regardless of wether it's a mutable
object or not you just need to pass a reference around.
[snip]
From the converse point of view, if you want a mutable object because
you know you'll change it, you mightn't want to limit your callers to
providing a mutable version of the object... ultimately it's easier to
call mutableCopy once in your target method than in some, most or even
all your callers. As with the immutable case just mentioned, if the
given object is already of the correct mutability you'll just end up
retaining it.
I think we're thinking the same way, but saying it differently.
What I thought I was saying was that, if you need a mutable copy
because you need to change it, you'd make one (probably by calling
mulatbleCopy). If you didn't you store a reference (probably returned
from retain). It doesn't matter if the class your working on is mutable
or not.
If everything was mutable, you should be incurring extra costs because
of unnecessary copies. Your code should only copy when it's necessary.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden