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: Mon, 7 Jun 2004 02:37:04 +0100
The practical reason for copying
You are replying to the theoretical reasoning with a practical
argument, but have snipped the practical reasoning. Anyway...
On the basis of theory, I could also say that there is nothing that
forbids it being copied. No ?
You can have a subclass of dictionary that does copying of keys. Call
it a NSStringKeySafeDictionary ...
There is absolutely nothing wrong with that. The problem is that you
can't easily/efficiently build a NSGenericDictionary on top of a
NSKeyCopyingDictionary, whereas you *can* build a
NSKeyCopyingDictionary on top of the NSGenericDictionary.
So having the NSKeyCopyingDictionary be the generic NSDictionary
behavior is, in a word, wrong.
Let me stress again that having such a capability present in some form
or another is not wrong!
Having mutable objects as keys is of course a pandaras box of
errors,
This is a theoretical fear. It isn't an practical problem.
Yeah sure. As long as you can pass in mutable strings as keys, and
have them be changed outside of the NSDictionary it is a practical
problem.
No. You have a practical problem if that is a problem that occurs in
practice frequently enough to warrant such a drastic measure.
I mean if that isn't a practical problem. I don't know what is.
Hmm...it seems you don't know what a practical problem is ;-)
I can't believe that you are unaware that this:
- (void) takeAString:(NSString *) s
{
[lut_ setObject:[NSCalendar date]
forKey:s];
}
Then don't believe it and try to re-examine what I've said from that
new perspective...
will create a hard to trace bug, if someone happens to pass in s as a
mutable string and changes the contents after calling takeAString:.
You did catch the fact that making a copy doesn't actually solve the
problem, because you can have keys other than strings.
How could you harden this code ? The only way is this, bloating the
user code (many places instead of one place (NSDictionary)):
- (void) takeAString:(NSString *) s
{
[lut_ setObject:[NSCalendar date]
forKey:[[s copy] autorelease]];
}
The *only* way? Have you heard of
(a) refactoring
(b) subclasses
(c) categories?
I really can't believe all the patently absurd claims I am reading in
this thread...
I think reading stringValue from a AppKit field editor gives you a
mutable string for example. I remember running into that problem early
on :)
Hmm...where does it make more sense to make a copy... ?
therefore the key gets copied.
You conveniently snipped my analysis of this part, so here it goes
again:
- copying the key is unnecessary, because you can easily specify
that requirement in the contract
How would you do that in Foundation ? Only by documentation, not very
safe...
Also this would "bloat" client code.
Not true.
- copying the key is unnecessary, because (string) keys typically
won't change, even if they theoretically could
Exactly. Typically(!) they wont change. But I already wrote something
about that...
Lovely, so we agree that the 'problem' that is being non-solved is
exceedingly rare.
- copying the key does not solve the problem, because copied items
can still change under you
But it solves the problem for the highest frequency key classes,
NSData, NSNumber and NSString.
Your argument is inconsistent at this point.
As we know, copy on immutable objects is usually just a retain.
Relying on a property of objects
What's the problem with that ?
Immutability is not something that actually works, as we have seem with
"immutable" arrays.
This retain would have to be done anyway, if you are not copying.
So it is not a design bug but a design choice and a good one.
In a word: no.
It is not a good design choice because it
(a) attempts to solve a problem that DOES NOT EXIST, practically
(and in fact pretty much relies on it not existing in the first
place!)
Does exist. You even say it doesn't appear "typically".
(b) then goes on to not actually solving the blasted problem
Does solve it for the vast majority of uses and usually at no extra
cost!
False. The "no extra cost" is only for those cases where it doesn't
occur! Duh!
(c) prevents uses of the class that are perfectly legitimate for a
dictionary
Yup, if it can't be copied it isn't served by NSDictionary. No
problem, as NSMapTable is there.
That is a workaround, not a solution.
(d) where other solutions exist that work at least as well if not
better without introducing these problems
I explained this before, but nobody seems to bother to actually READ my
posts before shooting from the hip...
Second, the definition is a mapping of (object) keys to values.
NOT of the key's value to a value. Since one of the fundamental
properties of objects is that they have identity (See RM-ODP and
other definitions of the term), the fact that a *different* object
is actually used as a key is, at the very least, an odd choice.
By that reasoning you would create two entries for
[dictionary setObject:@"foo"
forKey:[@"bar" mutableCopy]]; // yeah, leak, so what
[dictionary setObject:@"xxx"
forKey:[@"bar" mutableCopy]];
No.
What do you mean no ? How would that not create two entries ?
It *could* create two entries if it wanted to, but it doesn't have to
do this (and wouldn't, for strings).
[snip]
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.
| References: | |
| | >Ugly bug in Foundation, beware! (From: Ondra Cada <email@hidden>) |
| | >Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Alastair Houghton <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Ondra Cada <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Alastair Houghton <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Brent Gulanowski <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Alastair Houghton <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Ondra Cada <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Marcel Weiher <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Brent Gulanowski <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: "Louis C. Sacha" <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Marcel Weiher <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Nat! <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Marcel Weiher <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Nat! <email@hidden>) |