Re: dynamic binding in initializers
Re: dynamic binding in initializers
- Subject: Re: dynamic binding in initializers
- From: Kyle Sluder <email@hidden>
- Date: Thu, 24 Feb 2011 11:28:52 -0800
On Feb 24, 2011, at 8:06 AM, Ken Thomases <email@hidden> wrote:
> 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.)
This does have the unfortunate side effect of making otherwise sensible patterns impossible. For example, if you subclass NSWindowController, you most likely only ever want to associate that window controller with a specific nib. You might therefore want to override -initWithWindow: and -initWithWindowNibName: to assert, and implement -init to call [super initWithWindowNibName:@"MyNib"]. But alas, that will call your derived -initWithWindow, and you will trip the assertion.
Because -init is allowed to return an object other than self, you can't even set a flag ivar to change the behavior of -initWithWindow:. You're stuck either not overriding -initWithWindow:, or reimplementing the logic of -initWithWindowNibName: so that you can call [super initWithWindow:].
>
> 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.
Using a private InitInstance() function does seem like a workaround, but if you're vending a framework then you're essentially forcing your clients into the NSWindowController scenario.
--Kyle Sluder_______________________________________________
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