Hi Graham,
Thank you for such detailed explanation. I made a few changes except the
type check of what NSPropertyListSerialization returns. Ill be adding that
soon. Other than that, I wanted you to take a look at the changes I made
and let me know if you see any problems. I tested it, at it seems fine and
the warnings went away.
@interface TempConfig : NSObject {
NSMutableArray* ivarContents;
}
@property (retain) NSArray* contents;
- (void) setContents:(NSArray *)serializeObj
{
if (serializeObj) {
ivarContents = [serializeObj mutableCopy];
} else {
ivarContents = [[NSMutableArray alloc] initWithCapacity:10 ];
}
contents = ivarContents;
}
- (id) contents
{
return contents;
}
- (void) addTempObject: (id)object
{
[ivarContents addObject:object];
}
- (void) dealloc
{
[ivarContents release];
contents = nil;
[super dealloc];
}
+ (id) newTempConfigWithSource:(NSString*)source
{
TempConfig* config = [[[self class] alloc] init];
// Read contens from file
NSError *errorDesc = nil;
NSPropertyListFormat format;
NSData *plistXML = [[NSFileManager defaultManager]
contentsAtPath:source];
if( plistXML == nil ) {
[config release];
return nil;
}
// Serialize to array
[config setContents:(NSArray *)[NSPropertyListSerialization
propertyListWithData:plistXML
options:0
format:&format
error:&errorDesc]];
if( [config contents] == nil ) {
[config release];
return nil;
}
return config;
}
There are other methods where I would not be doing
NSPropertyListSerialization, in which case if I pass nil, the API will
allocate mutable array which will be used later using addTempObject method.
Regards,
Varun
On 4/04/2014 2:59 pm, "Graham Cox" <graham....@bigpond.com> wrote:
>
>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
