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: Marcel Weiher <email@hidden>
- Date: Thu, 3 Jun 2004 23:00:05 +0100
Ondra was making the point that -copy for an immutable object
generally
just -retains it, and in reply I was pointing-out that there are
plenty
of objects that are notionally immutable (in that you shouldn't
attempt
to change them), despite actually being mutable.
Quite right. That's exactly why I am copying the object, to get my own
immutable copy regardless which of the cases actually happened;
But that is just a fantasy. The fantasy of "value" semantics in a
language based on references. Won't happen, can't happen.
[snip]
Well that's a very good (and separate) question. I never saw a reason
for the presence of -arrayWithArray:, -dictionaryWithDictionary:,
because -copy and -mutableCopy seem to do the same thing and are
shorter and easier to understand.
That's I fear the very thing we are arguing here: whilst copy at the
moment indeed seems to do the same thing, it was definitely not
designed so,
Absolutely 100% wrong. It was very definitely designed to work in just
this way.
[snip]
As its name implies, it is there to "make a copy".
Yes. And that is what it does. At the top level.
That is--or at least
should be--something quite different from "making another array which
shares the contents".
Nope. That is the only thing it can reasonably do in the general case
of an array.
Think about (a) recursive references and (b) non-copyable objects
inside the array and this should become clear (almost) immediately.
If I make a copy of something, the copy won't change when the original
changes.
Sure it will! For example, if I load a bundle that contains a
category, this will affect both the original and the copy in just the
same way.
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*.
Welcome to programming with *references*! :-))
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.
Not in the least bit. Have you heard of this thing called
polymorphism??
They're collections of references to objects.
Right. Which is the exact reason why the immutability and deepness of
copy are that important:
Exactly. Now remember that mutability/immutability is not a generic
property of Objective-C objects. And that the appropriate depth of
copying is application specific.
since another object may share something
_inside_ your array, and -- with the current broken behaviour -- may
_change_ it _inside your copy_ Like in
This is not broken, it is the correct behavior. What is broken is your
misconception that you are getting value-semantics in a language that
has reference semantics. Although Apple have to take a pretty large
part of the blame for that, by promoting the various
mutability/immutability + autorelease gadgets as if they had those
properties in a general sense, despite the fact that they can never,
ever have them.
id a=[NSMutableArray arrayWithObject:[NSMutableArray array]];
id b=[a copy]; // should be mine, immutable, safe!
[[a lastObject] addObject:@"oops"];
NSLog(@"%@",b); // it was NOT immutable/safe, self-evidently. Oops.
Exactly. The bug here is the comment in line 2: "should be immutable
safe" and the assumption that that goes to the depth. This simply is
not possible!
I think at least part of the original confusion stems from the fact
that the mutability or immutability of a collection object has nothing
whatsoever to do with the mutability (or otherwise) of its contents...
You definitely have a point here: one has to adhere to some rules, of
course.
I kind of recall there used to be a convention not to put mutable
objects into immutable containers (on the other hand, you could put
anything into mutable ones), so far as you intended to copy the
containers without problems(*). Perhaps though my memory plays tricks
on me, although it surely makes sense from the copy-makes-a-snapshot
point of view.
(*) I even kind of recall there used to be a talk to programmatically
forbid putting mutable objects into immutable containers, and the very
reason not to was this "so far": since containers are used for many
tasks outside property lists and copying, it would not make real sense.
Exactly! You can sort of get "value" semantics with property lists
(only simple objects and simple containers, no outside references, no
references / object-graph). However, the property-list model is far
too restricted to be useful, and its properties do not extend outside
that limited scope.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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.