Re: + initialize docs conflict?
Re: + initialize docs conflict?
- Subject: Re: + initialize docs conflict?
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 31 Jan 2005 20:12:05 -0500
on 2005-01-31 6:53 PM, Ricky Sharp at email@hidden wrote:
> When reading up on NSObject's class method 'initialize', I found these
> two quotes in the docs:
>
> "Each class receives the initialize message just once from the runtime
> system."
>
> "Normally the runtime system sends a class just one initialize message.
> However, if for some reason an application or the runtime system
> generates additional initialize messages, it is a good idea to prevent
> code from being invoked more than once"
>
> I can see where an application developer may (accidentally?) have code
> to call initialize more than once. But why do the docs have
> conflicting statements regarding the runtime?
>
> I have no problem modifying my initialize implementations with a
> one-shot flag if need be. However, if the runtime is only ever suppose
> to call initialize once, I'll then file a bug against the docs.
I think it's something about subclassing, and so in rare situations your
+initialize method might be called more than once if you don't protect
against it. If you know that you or anybody else will never subclass, maybe
you don't need to bother with this. But the standard advice is to use that
weird (to the uninitiated) C 'static' flag to make sure your code never gets
executed more than once, anyway. I've always done that by rote, and I've
never had a problem:
+ (void)initialize {
static BOOL initialized = NO;
if (!initialized) {
// your once-only code goes here
initialized = YES;
}
}
It surely doesn't slow down your app worth worrying about.
To any readers who don't think that snippet makes any sense: go read K&R.
Basically, the 'initialized' variable will remain set to YES after the first
run, forever, despite the apparent command to reset it to NO in the first
statement of the method every time it is called. (And who was it who said
you don't really need to know C to write Objective-C Cocoa code?)
To the poster: I predict that your bug report will be closed really fast.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden