On 4 Apr 2014, at 2:40 pm, Graham Cox <graham....@bigpond.com> wrote:
> Thirdly, casting the return value of [NSPropertyListSerialization > propertyListWithData...] to NSMutableArray doesn't turn that object into a > mutable array - you've just forced the type system to stop helping you. > Certainly retaining it here is the wrong thing to do as well, since this code > doesn't own that object, and has no business retaining it. That's what the > analyser is trying to tell you. I've just noticed that the situation is even worse than that. [NSPropertyListSerialization ...] is declared to return an id. What is it? Could be anything. It might be an NSArray, might be a NSDictionary, might be a string - in fact there's no way to know unless you ask it. There is a way to specify that mutable objects are returned, though it's not that clear if this method supports it (the documentation appears to have a cut/paste error that suggests options are mutability options, but elsewhere they are read options which are unimplemented and require that you pass 0), but even if it does, you haven't asked for mutable objects. In this situation I definitely would be writing my own -setContents: method, and first thing it would do is to assert that the class of the parameter is NSArray. That way if someone screws up and deserializes a valid but unexpected property list, your code won't fail horribly, but instead can politely throw an exception. I'd also be copying that array into a mutable one if you need it to be mutable. Everyone's happy, including the crappy documentation writer who hasn't noticed his error. Code defensively. --Graham _______________________________________________ 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
