On Mar 3, 2014, at 01:47 , Graham Cox <[email protected]> wrote:
> On 3 Mar 2014, at 7:48 pm, Quincey Morris > <[email protected]> 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. > > Looking at it from the opposite point of view, if you have five objects in an > archive but only the first one is invalid and can't be initialized, then why > should it go on to drop the remaining four objects in that array? It > certainly doesn't stop it from dearchiving further objects in a different > array. Or, if the first two objects were fine, but number 3 was nil, then you > end up with two objects in the array instead of four. How is that behaviour > useful or consistent? What you get depends on the order of the items in the > array, which seems to me unintentional - if there were a (documented) rule > that says if any object is nil the whole array ends up empty then OK, but > right now it contains the objects up to, but not following, the nil object. It can certainly be true that for some unarchived arrays, dropping un-unarchivable elements is appropriate. You’re currently dealing with such a case. That’s a valid strategy for your app, but it’s not a valid strategy for the frameworks unarchiver classes: 1. It’s not true *in general* that an array is a list of objects whose index in the array is insignificant. *In general* it must be assumed that the index matters, so dropping elements is not a possible *general* strategy. 2. It’s disingenuous to argue that it “could” unarchive and keep the rest of the array elements, and that dropping them is wild behavior. The point is that you’re asking it to do something impossible (add a nil element to a NSArray). That’s your fault, not the unarchiver’s, so don’t blame it for giving up. 3. Unarchiving contains no standard error reporting mechanism. If it were to do as you say you wish, there’d be no indication that anything was wrong. (As it is, there’s no indication that anything was wrong with the array. *That* seems like a bug — it should probably throw an exception.) 4. IMO, it’s significant that an archive is an archive, not a mere data structure. That is, it’s a representation of an object graph that’s recoverable by unarchiving. Although there’s no clear documentation on this point AFAIK, it seems at least a bit code-smelly for an object that was in the object graph at archive time to just disappear at unarchive time. Of course, you can invent cases where this doesn’t matter, but again it’s not a viable general strategy. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
