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: Ondra Cada <email@hidden>
- Date: Thu, 3 Jun 2004 22:29:08 +0200
Alastair,
On 3.6.2004, at 19:35, Alastair Houghton wrote:
>
On 3 Jun 2004, at 17:19, Brent Gulanowski wrote:
>
> On Jun 3, 2004, at 10:44 AM, Alastair Houghton wrote:
>
>
>
>> 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.
...
>
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; had I
knew for sure it is "actually immutable", I could just retain.
And the very very same applies for the possible mutable contents of a
container!
>
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, and it should not IMHO.
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".
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*.
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.
>
They're collections of references to objects.
Right. Which is the exact reason why the immutability and deepness of
copy are that important: since another object may share something
_inside_ your array, and -- with the current broken behaviour -- may
_change_ it _inside your copy_ Like in
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.
>
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.
Cheers,
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
[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.