Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- From: Kyle Sluder <email@hidden>
- Date: Fri, 29 Jul 2011 16:10:23 -0700
On Fri, Jul 29, 2011 at 3:54 PM, <email@hidden> wrote:
> And this is one of several concerns with the NSCoding system. It may be that the reason these classes haven't been updated is because there's consternation over the value of such an update. Some people consider NSCoding intractably insecure and ergo unsuitable for use in pretty much anything. Others take issue with it for varied other reasons. I personally like it, but it's not flawless.
It's kind of cyclical. I treat anything loaded via NSCoding as code,
not data, because a) it's a frozen object graph, which means it is
tightly coupled to the implementation that was used to write the data,
and b) because of design decisions that make it fragile, like the one
Jerry has pointed out.
That motivates the designers of NSCoding to avoid making it more
general purpose, which perpetuates the cycle.
FWIW, NSCoding needs to be fast. It's used for unarchiving nibs. I
think its current role as a "code-loader" rather than a "data-loader"
is appropriate. There are better ways to persist data, such as
property lists or XML formats, that avoid common maintenance and
interoperability shortfalls.
--Kyle Sluder
_______________________________________________
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