On 24-Feb-2011, at 11:02 PM, Dave Zarzycki wrote: > Roland, > > Check this out: > > http://cocoawithlove.com/2008/03/cocoa-application-startup.html > > The code should arguably live in a +initialize method. > > davez
it can't - it's per-instance initialization. Were there one designated initializer for a UIView, I'd put my initialization code in there, knowing that everything would end up going through it. However UIView's (and possibly other classes) don't have a designated initializer, they can be called with initWithFrame: or initWithCoder: depending on whether they were initialized in code or unpacked from a NIB, hence I want to put my per-instance initialization code in one place and call it from both of those. My reuse of the name 'internalInit' for the method I used for that purpose blew me up when I inherited from one of my own subclasses which used the same pattern. I was hunting through the documentation to find a way of calling [ <this class you are actually in right now> someMethod ] so that I could name the method internalInit and be sure when I call it, I get mine, and if the superclass has its own it's going to call later, that will happen at that point. Nothing found however, seems a bit non-objective-C'ish. It seems if I have a method I really don't want to be dynamic, I should call it a class-specific name (which I just did, my internalInit is now internalInit_MyClass, ugly though)_______________________________________________ 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
