On 24/10/2009, at 8:19 AM, Michael de Haan wrote:
When adding a bookmark, the bookmark object is initialized thus:
- init
{
if (self = [super init])
While not strictly wrong, the above is not good style. If you enable
more warnings, this will be flagged as "possible unwanted assignment",
even though in this case it's a wanted assignment. Go with the pattern:
self = [super init];
if( self )
{
...
}
{
title = @"new title";
self.creationDate = [NSDate date];
}
return self;
}
**property declarations for title and creation date are @property
(copy) NSString *title // and NSDate * creationDate respectively**
Back in the calling method, creationDate is again called:
Bookmark *newBookmark = [[Bookmark alloc] init];
[newBookmark setCreationDate:[NSDate date]];
Is the reason that the date created in the initializer is an
autoreleased object, and thus the method adding the bookmark needs
it's own "owned" copy? Now I **thought** I understood this, but
"title" in the init method is directly assigned to it's ivar, and
also handed back to the calling method, without any further
intervention.......or should I read memory management again!!! :-)
No, the additional call to setCreationDate: appears to be redundant.
Whether it's there or not the date object is being memory managed OK.
This might be just a legacy of the way the code evolved - perhaps it
didn't used to assign its own date. No matter, it's not really an
issue. self.creationDate = ... will assign the date object to the
creationDate property using a copy which retains it, etc - the fact
that [NSDate date] is autoreleased is neither here nor there - the
bookmark makes a copy and retains it. The later call from the caller
just replaces the first one.
There is a lot of discussion about the fact that dealloc is not
necessarily called each time an object is disposed of. The rules of
memory management would seem to indicate that in the case of
initialization of doc.m:
- (id)init
{
self = [super init];
if (self)
{
collection = [[NSMutableArray alloc] init];
}
return self;
}
"collection" needs to be released. [ collection holds all the
bookmarks].
Now, there is no dealloc method called in this project's doc.m
So, my question is when is it appropriate to **omit** the dealloc
entirely?
In this case the missing dealloc is incorrect. You are right - there
should be one there that releases <collection>, assuming that the code
is running in a memory managed (as opposed to garbage collected)
situation.
Omitting dealloc is appropriate when a) you don't have any ivars that
are objects, i.e. scalar values only b) there is no other teardown
needed, such as stopping observing of a notification or other object,
and c) if b doesn't apply and you're running in a GC environment. To
put it another way, -dealloc is just another method, so it only needs
to be overridden if the ancestor class's implementation needs to be
extended for some reason. Some reason is usually memory management but
it can be for other purposes, such as de-observing.
--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
