Re: Can a subclass of NSDictionary do this?
Re: Can a subclass of NSDictionary do this?
- Subject: Re: Can a subclass of NSDictionary do this?
- From: James Quick <email@hidden>
- Date: Thu, 24 Jul 2003 17:12:33 -0400
On Thursday, July 24, 2003, at 04:48 PM, James Quick wrote:
On Wednesday, July 23, 2003, at 01:36 PM, Marco Scheurer wrote:
And IMHO, using key paths of length > 1 is usually not such a good
idea. Of course it's handy, but it breaks encapsulation. Better to
ask directly valueForKey "c" and let the receiver figure out how to
get > it.
Could you elaborate? It would seem to me that an abbreviated key
would obfuscate the
intention of the original writer. He's obviously intending his lookup
to produce a result.
What benefit offsets the cost of maintaining code that less clearly
states its purpose to the reader?
My questions were poorly chosen. I was confusing length of key path
with length of the
keys, and was trying to figure out why you thought looking for an
abbreviation is better.
oops.
I still disagree with your contention that longer key paths, are a bad
idea.
Asking for the value c may be a good choice in the case where names
within a
level are globally unique. In other contexts common names occurring in
each of
multiple subpaths, reflect a hierarchical order of common attributes
for different
enclosing objects.
Exporting the complexity of the search exposes more detail to the
consumer
which is irrelevant to his goals. He is given a key and needs to bind
it a value.
Delegating the details of the lookup to the storage medium seems like a
better
example of making use of encapsulation, hardly an act of breaking it.
It hides
the implementation detail from the user.
Yes, I understand that you don't like the fact that such a lookup makes
an implicit
assumption about the receiver and the types of it's contained objects,
e.g. that 'b'
is expected to be an instance of a Dictionary. I don't however see
that exporting
the lookup logic to the consumer is preferable.
_______________________________________________
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.