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: Tue, 8 Jun 2004 13:32:41 +0100
[
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".
-(void)takeAString:(NSString*)s
{
[lut setObject:[NSCalendar date] forCopyOfKey:s];
}
Whew, that was HARD! I think I am going to have to take the rest of
the day off.
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.
Wow! So you are also a member of Ondra's single-password society? I
think it needs to be resolved where you have the mutability, not in
every dictionary just in case.
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.
It would take two idiots to actually play tennis.
So let's see:
copying: [dict setObject:anObject forKey:key];
no-copy-needed: [dict setObject:anObject forKey:key];
(or was it the other way around?? can't remember...)
copying: [dict setObject:anObject forKey:key];
copy elsewhere: [dict setObject:anObject forKey:key];
(IMHO, 99.9% + are covered by the previous two cases)
copying: [dict setObject:anObject forKey:key];
category: [dict setObject:anObject forCopyOfKey:key];
copying: [dict setObject:anObject forKey:key];
subclass: [dict setObject:anObject forKey:key];
(or was that the other way around? can't remember...)
Wow, you are right! The code bloat is absolutely tremendous!! I bow
my head in shame. So maybe, just for you, we introduce a cover method:
copying: [dict setObject:anObject forKey:key];
nat-category: [dict setObject:anObject forCey:key];
See, no bloat! Happy now?
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.
Yes, as in: happens rarely in my lifetime.
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.
Maybe your programs are random string/mutable-string generators. Mine
aren't.
[snip]
- 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 ?
That is left as an exercise for the student. [Hint: look just above
this section at your own reasoning]
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.
Hurray! If the copy is just a retain, and you are so adamant that it
*is* just a retain, then let's *use* a retain instead of the copy that
may or may not be retain.
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 ?
Nope. I just don't want that mutable string as (a) value (b) member of
my set (c) element of my array either. So I am going to have get the
mutability of that string removed at some other point, at which point
it won't be problem for the dictionary either.
Let's play a little game, it's called "odd one out".
NSSet - client copies, if necessary
NSArray - client copies, if necessary
NSDict value - client copies, if necessary
NSDict key - dict copies, always
Can you tell which one is different?
[workarounds]
It exists and it works.
That is why it's called a *work*around, yes.
Looks like a solution to me.
If you think every workaround is a solution, then: yes. However, that
would mean that every bug for which there is a workaround is actually
not a bug at all.
NSDictionary is limited by the NSCopying requirement.
Precisely. That is a limitation. An unnecessary limitation, because
it is a non-solution (doesn't work) to a non-problem (has little or no
practical relevance). In my book, a design decision that causes an
unnecessary limitation is a design bug.
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.
[...]
Your previous mails in this thread didn't offer any solution except
just not copying,
Actually, I have given solutions on at least 3 different occasions, one
of them being in reply to you. You aren't reading. QED. Maybe you
should try *understanding* instead of *feeling*. Might work better.
which, as I have demonstrated, do introduce other more severe
problems.
Claimed, not demonstrated.
[identity]
NSDictionary as specified is using -hash and -isEqual:
Yes, and NSObject provides implementations, and the docs for hash
(which were posted here before) actually says that the hash it is doing
(independent of value!) is a good one for mutable objects placed in
collections!
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
It doesn't say that. On the contrary: it explicitly says that copying
is application dependent. Please don't start making up things. It
says "functional copies". Maybe you were scanning and thought it said
"functionally identical". But it doesn't actually say that. Read it
again. It also says "functionally independent". It just says "values
identical", but that requirement is met. So, no, what you are
inferring simply isn't there.
However, even if it *did* say everything you claim it does, that still
wouldn't make the copying behavior any better, it would just make it
more obvious how restricted NSDictionary is.
and that the object and its copy are expected to say YES to isEqual:.
It also doesn't say that, and there are reasonable objects that won't
do that.
This is something that you can infer from the NSCopying documentation.
Nope.
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.
What version of the docs are you looking at?
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
ObjC_classic/Protocols/NSCopying.html
"The NSCopying protocol declares a method for providing functional
copies of an object."
Or differently, why do you think the rationale for a NSCopying
protocol is there in the first place ?
I have never seen a rationale for the NSCopying protocol, and quite
frankly, find it somewhat superfluous. However, if you are saying that
all copying in the world should conform to one class's needlessly
whacky implementation, well, I guess that is your right in the sense of
"freedom of religion". I tend to have a more practical approach...
[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>) |
| | >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>) |