Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
- Subject: Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 3 Jun 2004 12:19:54 -0400
On Jun 3, 2004, at 10:44 AM, Alastair Houghton wrote:
>
On 3 Jun 2004, at 15:17, Ondra Cada wrote:
>
>
> Alastair,
>
>
>
> On 3.6.2004, at 15:49, Alastair Houghton wrote:
>
>
>
>> Are you certain that this is a bug?
>
>
>
> Sure I am. Among others, since...
>
>
As you may have gathered, I'm not convinced. I think it makes sense to
>
do a shallow copy.
>
>
>> I don't see where in the documentation for NSCopying it says that the
>
>> copy is necessarily a deep one, and it seems to make more sense in
>
>> most cases for a collection class's -copy to perform a shallow copy,
>
>> especially for the very common case where a collection is used to
>
>> hold a set of immutable objects.
>
>
>
> ... in this case a shallow copy is *the very same* operation as a deep
>
> copy, thanks to the fact an immutable object, of course, is not
>
> actually copied!
>
>
Well... that's true, although you might have a *notionally* immutable
>
object, rather than one that is actually immutable---e.g., an
>
NSMutableString that was returned via a method with an NSString *
>
result.
So you're suggesting that the receiver of said string, expecting an
immutable object, would then start sending it mutable messages? And
when it did not complain ... ? Sorry I don't really understand the
implication...
>
>
Here are a few more reasons that I think a shallow copy makes more
>
sense:
>
>
1. Deep copy is almost always an unnecessary expense. For the few
>
cases where a deep copy would be appropriate, you would take a hit on
>
*many* cases where it wasn't actually necessary.
But isn't it enough to have and use -arrayWithArray: (or
dictionaryWithDictionary: etc.) as Ondra said? Why have two methods
that do virtually the same thing?
>
>
2. Deep copying goes against the idea that collections are a collection
>
of references rather than a collection of objects. Yet the
>
collection-of-references point of view corresponds better (to my mind)
>
to what is actually going on in the system, and doesn't introduce
>
confusion over the possibility of modifying a mutable object held in an
>
immutable array (for instance).
Uh, so where is the collection of objects, then? I use Arrays as
collections of objects. If I want a collection of pointers, I can make
an id * and malloc an array. Where's the _value add_ of a collection if
it's just a bunch of pointers? ;-) I'm being facetious, I know, but
really I'm just disagreeing with the idea that a collection is not a
collection of objects, your descriptive (as opposed to prescriptive)
definition notwithstanding.
I'm still trying to figure out why one would want to both store a
mutable object in an immutable collection and then make a copy of that
immutable collection without copying the stored objects, when you can
just retain (or even just record a non-retained reference to) that
immutable collection, which is I thought the normal pattern. Unless,
again, you really want to use -<collection>with<Collection> ... ?
>
>
3. The mutability applies to the array, not to the objects in the
>
array; this is also true of immutable arrays... they can contain
>
mutable objects, which can be modified if that is what you want to do.
>
Granted, there are issues with dictionaries (as regards keys) and sets,
>
but those are fairly obvious to anyone with even an elementary
>
understanding of the kinds of data structures that might be used to
>
implement such a collection. They are also well documented.
I am getting a sense that there is a bunch of assumed relationships
between mutability and copying, which I am not sure are justified
(anyway it hasn't been proved to me). If I want a copy of an object
graph, I really don't know that I care which objects are mutable and
which are not. The mutability may only matter in the context of the
object graph itself, not anything outside of it. In other words, once
you make the copy, it's YOUR object. It no longer matters whether the
original was mutable, and since the copy is yours, you are now free to
do what you want with it.
>
>
4. It is difficult (and costly in terms of performance) to implement a
>
generic deep copy, because of the possibility of circularities or even
>
just several references to the same object in the data structure. On
>
the other hand, it is usually easy to implement a deep copy in any
>
specific case that you come up against.
Then don't use -copy. (?) Because apparently you don't want a copy, you
just want a duplicate collection with references to the other objects.
Such a duplicate is not a copy, since a collection itself has no copied
state except its objects. If you want a copy of a collection what you
really want is a copy of the objects in that collection. Shallow and
deep copying is done on a case-by-case basis, of course; if an object
does not respond to a copy message, then you make a shallow copy.
Otherwise the shallow vs. deep rules are only useful in a custom class,
and even then they are hardly rules, only being based on whether you
were copying or retaining (or merely referencing?) the instance
variables of said class.
--
Brent Gulanowski email@hidden
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.