On 25-Feb-2011, at 12:06 AM, Ken Thomases wrote: > 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 subclassin > > 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.) >
Ah yes I see - you're right - I've replaced the UIView's initializers with my own by doing this, and I understand why any subclass of my class should reimplement the UIView initializers calling the new designated initializer I've now forced upon the class. > > 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. I think I'm going to do it this way in this instance however. I'd like to keep the UIView subclass being a drop-in replacement for a UIView and having a user (even if it's only me next month) have to use it by calling an entirely different init method is a bit orthogonal to that. I suppose all I was really trying to do here is avoid typing the same initialization code into two init methods, by factoring it out into its own routine, this is a rather nicer way of doing that and a pattern I shall follow from now on in such cases. Thanks for the reply Ken (and Kyle). _______________________________________________ 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
