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: Nat! <email@hidden>
- Date: Tue, 8 Jun 2004 02:56:56 +0200
[some stuff snipped, where there isn't a disagreement]
Am 07.06.2004 um 03:37 schrieb Marcel Weiher:
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 ;-)
Or maybe I am just so advanced that only these trifles remain as my
practical problems :P
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.
Too gracious. Again funnily, I don't have the problem as I only use
NSStrings, NSData and NSNumbers as dictionary keys. Your black and
white reasoning just blows past the fact, that it indeed solves my
problem and those of the majority of cocoa coders. (see below)
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?
No sorry. Er... yes I have. Funny I almost forgot that.
Ok so put yourself to the challenge and figure out with subclasses,
categories and especially that power tool refactoring, how to make sure
that you don't end up with an NSMutableString as the key in a
dictionary in my method "takeAString".
Hmm...where does it make more sense to make a copy... ?
In Tor 1) 1 million (*) places in user code, where every time it is
forgotten you get a hard to trace bug, or Tor 2) in NSDictionary where
it will be done for us at no extra cost and less client bloat or Tor 3)
der Zonk. Hmmmmmmm... I'm gonna choose Tor 2.
(*) figure 1000 cocoa developers, writing 10 programs each using 100
different calls for NSDictionary, just to make this nice number :)
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.
True. (s.a.)
Idiotentennis.
- 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.
Ignoring non-solved, Yeah! But rare only in human terms. This becomes a
matter of statistics. Ponder on this: If your machine produces lets say
thousand keys a second, where only 0.1 promille is mutable. This means
that my performance is going to suffer by that 0.1 promille factor. But
if I forgot that copy, that hard to trace bug will hit me in 5 seconds
on average.
- 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.
Thanks for telling me. Unfortunately its very hard from your terse
comment to figure out, how it is inconsistent ?
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.
Has nothing to do with the argument that the copy is just a retain.
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!
You really want that mutable string as key, eh ? I don't, so the copy
is something I would have needed to do anyway. So extra cost for you,
none for me in cases where I need it.
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.
It exists and it works. Looks like a solution to me. NSDictionary is
limited by the NSCopying requirement. If your object can't implement
NSCopying properly (see far below), use NSMapTable.
(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...
I don't know. I happen to read your mails throroughly and I put some
effort into feeling your pain. I am afraid I can't detect that same
level of scrutiny in your responses.
Your previous mails in this thread didn't offer any solution except
just not copying, which, as I have demonstrated, do introduce other
more severe problems.
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).
You win on the last argument :) Depending on the implementation of
isEqual: this could indeed be either way even if only keys are used.
But again on the identity part:
NSDictionary as specified is using -hash and -isEqual:
I already indicated in my last mail - snipped and, judging from your
last mails, conveniently ignored by you - that a copy is expected to
have the same hash value and that the object and its copy are expected
to say YES to isEqual:. This is something that you can infer from the
NSCopying documentation. The idea is to make another instance, that
behaves at first identical (*identity*) to the original. It says so in
the very first sentences of the protocol description.
Or differently, why do you think the rationale for a NSCopying protocol
is there in the first place ?
You would probably have less problems if the NSCopying documentation
spelled out, that a copy is expected to have the same hash value and
that the object and its copy are expected to say YES to isEqual:. A
fact I think any competent coder is able to infer from the NSCopying
text anyway. But maybe Apple can just add that.
Ciao
Nat!
------------------------------------------------------
Die Genialen bleiben immer halbe Kinder, in Eitelkeit
befangen, und verlassen sich immer auf Intuition, und
bon sens und Sentiment und wie all die franzoesischen
Worte heissen moegen. -- Fontane
_______________________________________________
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>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Marcel Weiher <email@hidden>) |