Re: Debugging insight needed for NSKeyedUnarchiver
Re: Debugging insight needed for NSKeyedUnarchiver
- Subject: Re: Debugging insight needed for NSKeyedUnarchiver
- From: "email@hidden" <email@hidden>
- Date: Mon, 03 Mar 2014 10:56:45 +0000
On 3 Mar 2014, at 09:47, Graham Cox <email@hidden> wrote:
>
>
>> IAC, I don’t think it’s exactly about whether initWithCoder returns nil. Surely it’s about the fact that decoding a NSArray can’t deal with a nil element, since it can’t be inserted into the array. Simply dropping nil elements doesn’t even seem like a possible strategy.
>
> Why not? If I decode a list of objects into an array, it would be a very simple matter when looping over those objects to skip nil items. If the code uses -arrayWithObjects: instead, then that's a choice made by its designer, not the only possible way to do it. I would argue that it's definitely the wrong choice - it's making an assumption about how external code is operating.
>
I agree that skipping nil items seems, from our perspective, like a sound idea.
However, it is seemingly not to be.
It is hard to argue with the statement that you must return self from initWithCoder:.
Have you considered using:
- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder
The docs say:
If you have an advanced need that requires substituting a different object after decoding, you can do so in awakeAfterUsingCoder:.
This sounds like it might offer an out. I am not sure of the detail but the docs for -awakeAfterUsingCoder allow a substitute object to be returned.
Perhaps you use a single proxy object to represent all the invalid ones.
Otherwise it might be possible to return NSNull +null from -initWithCoder:, though that violates the -initWithCoder: stricture to return self.
When the archive is complete you can remove the proxies/NSNull instances from the collection.
Given that the object doesn’t decode it would be better if it wasn’t encoded in the first place; but I imagine that is a fait accompli.
Jonathan
_______________________________________________
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