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 (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

Reply via email to