Re: dynamic binding in initializers
Re: dynamic binding in initializers
- Subject: Re: dynamic binding in initializers
- From: Ken Thomases <email@hidden>
- Date: Thu, 24 Feb 2011 10:06:38 -0600
On Feb 24, 2011, at 9:21 AM, Roland King wrote:
> 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.
So, your class _does_ have a designated initializer. Therefore, all of its subclasses should follow the appropriate patten when subclassing.
Any class or yours which directly inherits from UIView should cover initWithFrame: and initWithCoder: and invoke its designated initializer. Any of its subclasses, though, should only invoke [super yourDesignatedInitializer:...], not [super initWithFrame:...] or [super initWithCoder:...]. (Such a subclass may or may not cover -initWithFrame: or -initWithCoder:, as needed, but should forward to its designated initializer, which would call down to super's designated initializer.)
> 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.
In other words, you didn't follow the rules for designated initializers among your own classes.
> 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)
Non-dynamic dispatch is done with C-style functions. If a function is within the @implementation, then it has all of the same access rights to instances and their variables. You can pass 'self' as a parameter and then use 'self->ivar' to access your ivars.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden