Re: Dictionaries vs iVars
Re: Dictionaries vs iVars
- Subject: Re: Dictionaries vs iVars
- From: Gordon Apple <email@hidden>
- Date: Mon, 02 Jul 2007 18:26:14 -0500
There are two types of classes I am thinking of doing this with: Draw
lists; Presentation hierarchy lists. Putting all iVars in a Dictionary may
not be appropriate for everything.
> This may leak the implementation to any object that interact with a
> graphic object, and will make it very hard to change it later.
I'm not sure what the problem is here since the plan is that only the
inspector, renderer, and controller would normally access the parameters.
> 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.
Why use global constants? I thought that was part of what you get rid
of when using key names. I used to have a lot of enums in C++ but that was
because C++ liked numbers for identifiers instead of keys.
>
> 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.
The main objects accessing the params can just access the dictionary and
then extract what they need.
>
> 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.
This seems like a general issue like functions passing Ids in Objective
C rather than specific pointer types in C++.
>
> 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"]
No argument here.
>
> Last, there is the documentation issue - how do you document which
> keys are legal for each class?
I think that is part of the advantage. If an irrelevant key is passed,
the renderer does nothing with it. For example, a fill color for a line
object would be ignored.
I think this should work because I learned a long time ago to have only
one type of draw object with a type id rather than the classical
multi-subclasses of draw types. It also makes it a lot easier to transmute
draw objects, such as changing a rectangle to an oval (or an outline of an
elephant). New shapes can be added in XML lists.
Although I'm not quite sure how to do it yet, I think it would be
relatively easy to dynamically add new rendering code for new properties,
such as putting a fancy frame around an object or embedding a new media
type.
_______________________________________________
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