Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.objective-c > #231

Re: A question on designated initializers

Show all headers | View raw

In article <n32tc0$hik$1@news.albasani.net>,
 Jon Rossen <jonr17@comcast.net> wrote:

> < A bunch of previous stuff cut out...new comments inline below>
> thx -jonR
> 
> >> Don, Thanks so much for your response with all of this info; I really
> >> appreciate it.  It is the perfect combination of theory and practical
> >> info.  You are right, I sort of understand the chaining mechanism in how
> >> things unfold in the class hierarchy.  The construct that you
> >> illustrated here with the default values used by the 'convenience' init
> >> methods is something I came across earlier today coincidentally, but
> >> your explanation was much more specific, to the point and not obfuscated
> >> by vague implications.  I have a few more questions:
> >>
> >> 1. Just a workflow question:  Re: the 'convenience' init methods that
> >> may be helpful to get objects accompany the designated one:  Is it
> >> typical for a developer when building a class to add the 'convenience'
> >> init methods later on or sort of on an 'as needed' basis depending?  I'm
> >> not asking this as to what's good or bad, but am assuming it just
> >> depends on the situation and in your experience how does this usually
> >> play out?
> >
> > I can't speak for anyone but myself, so YMMV...
> > Personally, I code a "designated" initializer that takes appropriate
> > inputs and uses them to handle *EVERYTHING*, to start with, then a
> > "naked init" ("-(MyClass *)init") method that passes some reasonable
> > defaults into the designated initializer. Often, but nowhere near
> > always, that's all that's needed. (Or more accurately, it's *ALWAYS* all
> > that's *NEEDED*, but it's only occasionally all that's *WANTED*, if you
> > understand the distinction) If, as the project progresses, and I notice
> > a need for them, I might add more convenience initializers. The decision
> > to add more convenience initializers or not is totally dependent on the
> > needs of the specific project - In one project, I might code the
> > designated initializer, the cover for "init", and several variations, as
> > needed. In another, I might not code anything except the designated
> > initializer, and a cover for "plain" init so that any subclasses I (or
> > someone else...) might cook up later will chain back up the line
> > properly when hit with a "[super init]". Either way, if somebody
> > subclasses from your class, they come in with the expectation that doing
> > "[super init]" will do the right thing (by calling the root object's
> > init method - perhaps directly, or perhaps through a very long and
> > complex chain of calls, but it'll happen eventually)
> 
> Ok....but backing up to the beginning of your paragraph:
> Hmmm, you lost me when you brought up your 'naked init' and said that it 
> 'passes some reasonable defaults into the designated initializer'.  The 
> naked init in the current class just calls the current class' designated 
> initializer and returns it.  How does it pass some reasonable defaults 
> *into it*??  Might you be referring to the naked init that is the 
> *superclass* of the current class?  Certainly the super's init does that 
> when you do self = [super init].  I just don't understand how the init 
> at the current level feeds anything into the designated initializer at 
> that same level.

(I'm going to proceed assuming we're both talking about the code snips 
that are down below, not anything that might have been mentioned in the 
pruned material) 

When the naked init makes the call to the DI, it passes an NSDictionary 
of default values (which I assume gets set up elsewhere)

> 
> 
> >> 2. Ok, hopefully this question won't open up a can of worms.  What about
> >> sub-classes?  I guess this is a two part question:
> >>    a) If there's a sub-class that doesn't particularly need it's own
> >> class designated initializer, it could just use it's super's designated
> >> initializer, correct?  If so, is this a common design pattern?
> >
> > At least in theory, yes, that's correct. As for how common it is...
> > <shrug> No clue - I've never actually taken the time to think about it.
> >
> > (minor nitpick: "it's" is a contraction meaning "it is" - You're looking
> > for the possessive form: "its" - "that which belongs to it". Ain't it
> > wonderful how consistent the english language is? :) )
> 
> Yeah, yeah, I know all of that; it was purely a typo due to being tired. 
>   When I get tired I have a tendency to spell fenetically :-) and little 
> details drop off by the wayside.  But great nitpick...I'd give it a 9 
> out of 10 at least.  :-)

The finest (and possibly most maddening!) example of apostrophe abuse 
I've ever encountered was a roadside stand with a sign I used to have to 
drive by at least twice daily - Half a sheet of plywood painted sky blue 
then in wonderful, almost calligraphy-like script, hand painted in 
screaming brilliant red, so it gave the illusion of "vibrating":
 FRESH
 EGG'S
4-SALE!


AUGH!!!!!! <facepalm - really really hard!>
  
> 
> Speaking of nitpicks, in your code examples why don't you use 
> (instancetype) as your return type?

Uh... 'Cuz I'm not returning an instance type, I'm returning an instance 
of a class?

> 
> >
> >> b) If the sub-class *does* need a designated initializer, I suppose it
> >> could do an override of the super's version and that would be ok.
> >> However, I would think that any additional initialization would have to
> >> be done via assessor methods as the method names would have to be the
> >> same.
> >
> > Sounds right... I THINK - Assuming you're asking what I think you are.
> 
> OK.
> 
> > If you're expecting to be subclassing off your subclass, then write your
> > "first level" subclass - let's call it MyClass - like so:
> > (I'm assuming you're on a Mac, so you'll probably be subclassing it from
> > NSObject)
> 
> 
> >
> > Your .h file has (at least - perhaps MUCH more) in it:
> > ---cut---
> > #import <Cocoa/Cocoa.h>
> >
> > @interface MyClass : NSObject
> > {
> >     // MyClass specific vars
> >     NSDictionary *myClassVars;
> > }
> > // And some method declarations
> > -(MyClass *)designatedInitializer:(id)anyNeededParams;
> > -(MyClass *)init;
> > // More stuff will likely live here in a useful program.
> > @end
> > ---cut---
> >
> > And in your .m file:
> > ---cut---
> > #import "MyClass.h"
> > @implementation MyClass
> >
> > -(MyClass *)designatedInitializer:(id)anyNeededParams
> > {
> >     self = [super init]; // Invoke NSObject's init
> >
> >     // Do MyClass-specific init
> >
> >     // and return what self has become.
> >     return self;
> > }
> >
> > -(MyClass *)init
> > {
> >     // I'll assume defaultParams is set appropriately elsewhere
> >     return [self designatedInitializer:defaultParams];
> > }
> >
> > // Any other methods MyClass needs follow
> > @end
> > ---cut---
> >
> > Notice that all init does is call the instance's designated initializer
> > with default params. Which in turn calls [super init] (NSObject's, in
> > this case)  before using the parameters it gets passed. You get the rest
> > of your MyClass going, ship the project, and make a few bucks.
> 
> Right.  This code example is pretty much the same example you showed me 
> the other day, and BTW, is consistent with my understanding of how to do 
> this.  So, there's nothing new here with respect to the other day's 
> example, right?

Other than being "more refined", no, not really - hang with me till 
after the next blob... 

> 
> >
> > Time passes, and a project you just got handed wants something very
> > nearly identical to MyClass, but with a couple little additions and
> > tweaks. You decide to subclass from MyClass to make a new class of
> > object -  The MySubclass
> >
> > You toss together a quick .h file:
> > ---cut---
> > #import "MyClass.h"
> > @interface MySublass : MyClass
> > {
> >     // MySublass specific vars
> >     NSDictionary *SubclassVar;
> > }
> > // And don't forget the method declarations
> > -(MyClass *)designatedInitializer:(id)anyNeededParams;
> > -(MyClass *)init;
> >
> > @end
> > ---cut---
> >
> > And the .m file
> > ---cut---
> > #import "MySubclass.h"
> > -(MySubclass *)designatedInitializer:(id)anyNeededParams
> > {
> >     self = [super init]; // Invokes MyClass' init
> >
> >     // Do MySubclass-specific init work
> >
> >     // and return what self has become.
> >     return self;
> > }
> >
> > -(MySubclass *)init
> > {
> >     // I'll assume defaultMySubclassParams is set appropriately somewhere
> >     return [self designatedInitializer:defaultMySubclassParams];
> > }
> >
> > // Any other methods MySubclass needs follow
> >
> > @end
> > ---cut---
> >
> > You'll notice how close to identical the code is for both cases - The
> > critical consideration is that you ALWAYS want your class' "init" to
> > chain back to the root object, whether directly or indirectly.
> 
> Not only are they close, aren't they basically *the exact same code* 
> structurally?  Meaning apart from the class-specific stuff that would be 
> needed (different name of designated initializer, additional parameters, 
> etc., etc.), the framework here is exactly the same as it was for the 
> subclass (MyClass).  I would *expect* it to be the same seeing that it's 
> keeping the init chaining intact.  Am I missing something or am I 
> 'getting it'?

You're getting it. Sorry if I seemed like I was beating you over the 
head with it - I caught a case of "If I actually THINK about how to tie 
my shoelaces instead of just letting my fingers take care of tying them 
for me "automagically", I'll do nothing but tie 'em in knots" syndrome, 
and the reply is partly me "untying" the knots I got myself into! When I 
got done, I decided it was worth going ahead and posting anyway in case 
somebody else might stumble on it and find it useful, tweaked a couple 
of typos, and hit send.
> 
> >
> >> c) At each step down the hierarchy through sub-classes, the 'plain' init
> >> would have to be overridden and it would have to return the current
> >> class' designated initializer, correct?  In other words, you'd have to
> >> re-write init for each sub-class where there is a new designated
> >> initializer.

Quickie comment here as I see some confusion in your reply to Pascal - 
When the plain init method is called, the caller doesn't get the current 
class' designated initializer - it gets THE RESULT OF CALLING the 
current class' designated initializer - an initialized and ready-to-use 
instance of a subclass that inherits from the current class.

> >
> > Basically, yes. See the snippets above.
> 
> Yep, my above two comments discusses this.
> 
> thanks for your response.
> -jonR

-- 
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q

Back to comp.lang.objective-c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-22 13:39 -0800
  Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-22 14:48 -0800
    Re: A question on designated initializers Louis Wu <louiswu@ringworld.net> - 2015-11-22 16:26 -0800
      Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-22 17:24 -0800
        Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-23 02:39 +0100
  Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-23 01:18 +0100
    Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-22 16:49 -0800
      Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-23 02:02 +0100
        Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-27 17:19 -0800
          Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-28 13:22 +0100
            Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-28 17:37 -0800
              Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-29 03:45 +0100
  Re: A question on designated initializers Don Bruder <dakidd@sonic.net> - 2015-11-22 19:15 -0800
    Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-23 18:44 -0800
      Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-24 04:58 +0100
        Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-24 16:42 -0800
          Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-25 02:00 +0100
        Re: A question on designated initializers Greg Parker <gparker@apple.com> - 2015-11-25 01:25 -0800
      Re: A question on designated initializers Don Bruder <dakidd@sonic.net> - 2015-11-24 07:38 -0800
        Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-24 15:54 -0800
          Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-25 01:49 +0100
            Re: A question on designated initializers Don Bruder <dakidd@sonic.net> - 2015-11-24 18:51 -0800
              Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-25 04:41 +0100
                Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-25 00:25 -0800
                Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-25 14:16 +0100
                Re: A question on designated initializers Jon Rossen <jonr17@comcast.net> - 2015-11-25 17:30 -0800
                Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-26 03:03 +0100
                Re: A question on designated initializers Don Bruder <dakidd@sonic.net> - 2015-11-25 09:08 -0800
                Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-11-25 18:41 +0100
                Re: A question on designated initializers Don Bruder <dakidd@sonic.net> - 2015-12-02 14:37 -0800
                Re: A question on designated initializers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2015-12-03 00:58 +0100
          Re: A question on designated initializers Don Bruder <dakidd@sonic.net> - 2015-11-24 18:29 -0800

csiph-web