I have an object class which maps to a CoreData object. Each instance of this object contains a one-to-many relationship to a set of subsidiary objects, each of which describes an event. That is, each main object has an array of events.
Now there are a number of different event types (around a half-dozen or so), each with its own associated data. That is, different events use different data. I am trying to figure out the best way to represent this situation in both CoreData and Swift. Here’s what I’m thinking: >> From a Swift perspective, an Event object would contain a Swift enumeration >> as a data member. This data member would map to an integer (its value) in >> the associated CoreData object. >> The enumeration-specific data would be represented in CoreData by a >> Transformable field that mapped to an NSMutableDictionary in the Event >> object. >> In C++, I’d write Event<T> as an abstract class, then construct a set of >> explicit template specialization classes that handles each valid value of >> the enumeration type T. Event<T> would contain the dictionary; each >> specialization would contain data members for the specific data items that >> event-type used. >> The question is whether this is a good (or even viable) model for a Swift >> implementation. I can envision using the enumeration’s associated data to >> store the event-specific data. I can also envision using generics to >> implement what I’d call template specialization if I were writing in C++. >> On the data side, actual classes could store data in data members (moving >> data between the dictionary and local storage explicitly) or it could >> implement data members that hid dictionary keyed-access behind the scenes >> (i.e. the getter call event.foo is implemented via accessing the “foo” key >> of the dictionary). So my question: does this make any sense? Is anyone out there dealing with this type of problem, and if so have you thought of a better approach? If you had a problem like this, how would YOU tackle it? Since I’m a Swift newbie (well, I guess everybody still is, but I’m more so than most), I would appreciate any thoughts or suggestions for the best way to tackle this problem. Thanks. Cheers, Rick Aurbach Aurbach & Associates, Inc. _______________________________________________ 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
