Re: Dictionaries vs iVars
Re: Dictionaries vs iVars
- Subject: Re: Dictionaries vs iVars
- From: Nir Soffer <email@hidden>
- Date: Mon, 2 Jul 2007 11:03:40 +0300
On Jun 27, 2007, at 23:54, Gordon Apple wrote:
I'm still toying with the idea of using dictionaries instead of
iVars in
my graphics objects and other types of data objects. My thinking
is to have
only one type of graphic object with a single dictionary and let the
relevant controller dynamically add properties as needed, e.g.,
shadows,
borders, shaders, content (pictures, QT, text, etc.) These can all be
accessed by key value by the renderer and editor. This seems like
it would
be a tremendous simplification of design and would offer great
flexibility
for later feature additions. It seems like it could simplify the
inspector
interface. It could also make it easy to view data structures when
needed
without having to resort to the debugger (e.g., field maintenance).
This may leak the implementation to any object that interact with a
graphic object, and will make it very hard to change it later.
This lead to fragile code, (e.g. CoreImage), when you have to copy
and paste key names from the docs to prevent hidden typing errors, or
have too many global constants with the key names.
This also create quite noisy code: [obj objectForKey:@"foo"] vs [obj
foo], [obj setObject:@"bar" forKey:@"foo"] vs [obj setFoo:@"bar"].
When you use global constants, it become even worse: [obj
setObject:@"bar" forKey:PrefixFooKey]
I would use a dictionary to simplify the code, but hide it behind
accessors. If you decide later to keep some values in ivars, client
code will not change.
Another problem to consider is compile time checking - when you use a
dictionary, you can fill it with junk, and you will not get any
error. You can solve this by set of allowed keys for each class,
checked at runtime, but this will add even more overhead. You will
have to profile the code to see if it matters.
Simple values in the dictionary will have to be boxed in NSNumber and
NSValue etc. The client code will have to box and unbox the values
everywhere. This is also something the can be hidden by accessors.
For example: [obj setBorder:0.5] vs [obj setObject:[NSNumber
numberWithFloat:0.5] forKey:@"border"]
Last, there is the documentation issue - how do you document which
keys are legal for each class?
Best Regards,
Nir Soffer
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden