On Jun 17, 2014, at 4:16 PM, Trygve Inda wrote:
>> Doesn't seem weird to me, I do it all the time. One advantage of using a
>> custom class over a dictionary is that the compiler knows what's expected of
>> it, while a dictionary is just a black box.
>>
>>
>> On Jun 17, 2014, at 3:21 PM, Trygve Inda wrote:
>>
>>> I need to store a large collection of settings (not application preferences,
>>> but parameters describing how complex data is to be displayed) and am
>>> looking for pros/cons as to the best way.
>>>
>>> At the top I have a class called MySettings. Within this I need to have
>>> groups of related settings. They can either be NSMutableDictionary or a
>>> custom class containing properties, but no methods.
>>>
>>> @interface MySettings : NSObject
>>> {
>>> MySettingsAppearance* appearance; // size, graphic style etc.
>>> MySettingsColors* colors; // colors for different elements
>>> MySettingsLocations* locations; // array of data
>>>
>>> ... About 8 more like these ...
>>> }
>
> Would you use a class-naming scheme like I have outlined?
It looks overly generic to me, but I assume you simplified it for the list,
especially since you said your main class was already MySettings :)
When it's associated with another class like that, I'd do something like use
the owning class (MySettings) as a prefix - so maybe MySettingsConfiguration.
But then a lot of time I'm using this for C++ structs, so foo::Bar::Struct
becomes MyFooBarStruct (namespaces! So awesome! But I guess we aren't ever
getting them for Cocoa now :( )
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
