Making an object release itself?
-
Im still learning cocoa, so I have a question about if this is a good
idea or a crazy noob mistake. Given the following code can I alter it so
that postreader auto releases itself?
-(IBAction) fetchThreads:(id) sender {
[progress startAnimation:nil];
PostReader* reader = [[PostReader alloc] init];
[reader loadLatestPosts: self];
}
// Callback message
-(void) postsRead {
[progress stopAnimation:nil];
}
Does it make sense that I could clean up things to work more like this:
-(IBAction) fetchThreads:(id) sender {
[progress startAnimation:nil];
[PostReader loadLatestPosts: self];
}
-(void) postsRead {
[progress stopAnimation:nil];
}
I'm thinking PostReader class could have a static function that
initialises a new PostReader object, tells it to start the work, and
then do a [self release] after it has called the callback function
'postsRead';
Thanks! -
On Wed, 31 Dec 2008 14:28:44 +1100, Jacob Rhoden <lists...>
said:> I'm thinking PostReader class could have a static function that
> initialises a new PostReader object, tells it to start the work, and
> then do a [self release] after it has called the callback function
> 'postsRead';
There is certainly nothing wrong, on the face of it, with an object telling
itself to release. This is quite common for singleton and temporary objects
(just what you're dealing with). m.
--
matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119> -
Le 31 déc. 08 à 18:28, Matt Neuburg a écrit :> On Wed, 31 Dec 2008 14:28:44 +1100, Jacob Rhoden <lists...>
>>
> said:
>> I'm thinking PostReader class could have a static function that
>> initialises a new PostReader object, tells it to start the work, and
>> then do a [self release] after it has called the callback function
>> 'postsRead';
>
> There is certainly nothing wrong, on the face of it, with an object
> telling
> itself to release. This is quite common for singleton and temporary
> objects
> (just what you're dealing with). m.
Just take care to call release at the very end. Once release is
called, accessing an ivar may crash your app. -
On Dec 30, 2008, at 10:28 PM, Jacob Rhoden wrote:> Im still learning cocoa, so I have a question about if this is a
> good idea or a crazy noob mistake. Given the following code can I
> alter it so that postreader auto releases itself?
[...]> I'm thinking PostReader class could have a static function that
> initialises a new PostReader object, tells it to start the work, and
> then do a [self release] after it has called the callback function
> 'postsRead';
In a retain/release world, having the helper object own itself, and
remove that reference when its async work is complete (and it has
posted the results somewhere) is generally OK.
If you intend this code to work in a GC environment though, you must
make sure your helper object is rooted, or some other object keeps a
strong reference to it, until the async work is complete, otherwise it
will be collected.
Jim -
Le 1 janv. 09 à 20:00, Jim Correia a écrit :> On Dec 30, 2008, at 10:28 PM, Jacob Rhoden wrote:
>
>> Im still learning cocoa, so I have a question about if this is a
>> good idea or a crazy noob mistake. Given the following code can I
>> alter it so that postreader auto releases itself?
>
> [...]
>
>> I'm thinking PostReader class could have a static function that
>> initialises a new PostReader object, tells it to start the work,
>> and then do a [self release] after it has called the callback
>> function 'postsRead';
>
> In a retain/release world, having the helper object own itself, and
> remove that reference when its async work is complete (and it has
> posted the results somewhere) is generally OK.
>
> If you intend this code to work in a GC environment though, you must
> make sure your helper object is rooted, or some other object keeps a
> strong reference to it, until the async work is complete, otherwise
> it will be collected.
>
Or you can use -[NSGarbageCollector disableCollectorForPointer:/
enableCollectorForPointer:], or CFRetain/CFRelease functions (that
prevent collection too).> Jim
>
