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: Philippe Mougin <email@hidden>
- Date: Fri, 4 Jun 2004 01:21:15 +0200
Ondra Cada wrote:
> whilst copy at the moment indeed seems to do the
> same thing, it was definitely not designed so,
> and it should not IMHO.
Ondra, I think this is not a bug and, more importantly, this is the
desirable behavior.
> As its name implies, it is there to "make a copy".
> That is--or at least should be--something quite
> different from "making another array which
> shares the contents".
You seem to view the objects referenced in an NSArray as part of the
content of the array. But this is not the case. Semantically (from an
abstract data type point of view), the content of an NSArray is only
made of *references* to objects, as many already wrote in this thread
before. Here, "reference" means something equivalent to "foreign key"
in a relational model.
The purpose of an NSArray is to store references to objects. The
referenced objects should be considered external to the array, not part
at all of the content of the array, and thus not copied when the array
is copied. Only the references are part of the content of the NSArray.
When we copy it, what we want is another array with a similar content,
that is, containing the same references, not other references to copies
of the objects referenced by the original array (*this* would be a
bug).
When we copy a pointer (for example, by assigning it to another
variable) we don't expect the data referenced by our pointer to be
copied, right? That is, we don't consider that the content of a pointer
is made of the pointed data. NSArrays and collections in Cocoa have the
same semantic: they are sets of pointers. This is a very fundamental
and useful semantic, on top of which higher-level (but less versatile)
things like deep copy or snapshot systems can be implemented and used
when needed.
> If I make a copy of something, the copy won't change
> when the original changes. If the original contained
> something (say, a newspaper with images),
> the contents of the copy does not change when
> the contents of the original changes. That's
> why it is called a *copy*.
Yes, but a newspaper with images does not hold references to external
things.
I think a more appropriate analogy would be, for instance, my car
insurance certificate. It contains a reference to my car (i.e., a small
set of alphanumeric characters that uniquely identify my car). When I
do a reproduction of my insurance certificate using a photocopier, the
copy has the same content as the original: they both refer to the same
car. The car itself is not duplicated (that would be quite cool but
this is another story).
> And that's the reason of +arrayWithArray:. It's here
> for cases you need another array with the same
> (means shared) contents: it's a different thing
> than a copy, and therefore you use a different
> message for that.
+arrayWithArray: has the same semantic than -copy (i.e. it doesn't
perform a deep copy). But still, it is not redundant. Indeed, by
invoking it on the receiver you specify, you can dynamically and
polymorphicaly choose a factory for your new array (quite useful if you
have developed various NSArray subclasses), something not provided by
-copy.
Best,
Philippe Mougin
F-Script: Open source scripting language for Cocoa!
http://www.fscript.org
_______________________________________________
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.