On Mon, Sep 29, 2008 at 3:03 AM, Negm-Awad Amin <[EMAIL PROTECTED]> wrote:
>> But now I find there is an even more natural way, which is to just leave >> them as a set or array, and store in an attribute of type Transformable. >> The default transformer en/decodes the collection into/from an NSData, and >> everything "just works". >> >> I'm surprised that I've never seen this discussed or documented. Is this >> going to get me into any trouble? > > Yes, because you get redundant and inconsistent model. If I'm reading this right, Jerry has a simple attribute called "pet names". Usually this is used as a personally-identifiable unit of information. Sure, lots of people might have fluffy, but do you really need to have a "PetName" entity, checking to see if an instance with "name" property equal to "Fluffy" exists, creating one if not? In this case (where we just want to store a short list of very personal things as an attribute), sure you can archive an array or a set, just like any other archiveable object. Now if the application needs to track people and their pets, I'd imagine you'd have a whole "Pet" entity with a "name" property, but that doesn't sound like what Jerry is getting at ... The 'correct' approach depends entirely on the model. -- I.S. _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
