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

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

Re: A question on designated initializers

From "Pascal J. Bourguignon" <pjb@informatimago.com>
Newsgroups comp.lang.objective-c
Subject Re: A question on designated initializers
Date 2015-11-25 14:16 +0100
Organization Informatimago
Message-ID <878u5muslu.fsf@kuiper.lan.informatimago.com> (permalink)
References (4 earlier) <n32tc0$hik$1@news.albasani.net> <87oaeivr7a.fsf@kuiper.lan.informatimago.com> <n337jb$6mt$2@dont-email.me> <87d1uyvj8a.fsf@kuiper.lan.informatimago.com> <n33r9o$27f$1@news.albasani.net>

Show all headers | View raw

Jon Rossen <jonr17@comcast.net> writes:

> Pascal, I also noticed that you and Don had different code for the
> designated initializer and forgot to ask about it; thanks for bringing
> it up.
>
> Don uses:  self = [super init];
> while you use: self = [super designatedInitializer];
>
> I'm not sure if I'm following your code path here.  If someone uses
> Don's method, [super init] is called, and it returns a
> designatedInitializer message to self.  Then you lose me when you say
> which will call [MySubClass designatedInitializer]' which as you say
> will give an infinite loop.  I don't understand the call to
> [MySubClass designatedInitializer].


You have to understand the difference between a MESSAGE and a METHOD.

To send a message we indicate:

- a recipient object for that message, (eg. self);
- a selector, (eg. designatedInitializer:);
- arguments, (eg. defaultValue).

Sending a message is therefore written:

   [self designatedInitializer:defaultValue]

The selector is denoted as designatedInitializer:

In code, we'd use the SEL macro:

   SEL(designatedInitializer:)

When sending a message is executed, there is a dispatching to a method.
That is, at run-time, the Objective-C runtime will try to find a method
matching the selector for the recipient object (which can also be a
class, classes are objects). 
Dispatching works like this:

- find the class of the object (if it's a class, find the metaclass);

- search a method for the selector in that class.

- if there is no method for the selector in that class, then search in
  the superclass, and so on.


When we send a message to super, we start the search directly from the
superclass, instead of starting from the class.

So when a method is found, such as -[SomeClass designatedInitializer:]
then it is called.  A method is basically a C function with two
additionnal parameters (a selector _cmd, and the recipient self).

Notice that methods are denoted by:

- a sign - for instance methods (stored in the class), + for class
  methods (stored in the metaclass).
- a class name,
- a designator.

  -[SomeClass designatedInitializer:]


So you can have two methods:

  -[MyClass designatedInitializer:]
  -[MySubClass designatedInitializer:]

and when you send a designatedInitializer: message:

   [self designatedInitializer:42]

one or the other method may be called first, depending on the class of
self.  

The class of self is not necessarily the class of the method being
executed!

Usually, the class of self is a SUBCLASS of the class of the method
being executed.



The problem with Don's code is that there are four methods:

  -[MyClass init]
      [self designatedInitializer:default]

  -[MyClass designatedInitializer:]
      …

  -[MySubClass init]
      [super init]

  -[MySubClass designatedInitializer:]
      [super designatedInitializer:default]


[MySubclass alloc] returns an instance of MySubClass.
The only instance we'll have is of the class MySubClass.

Sending the message [[MySubclass alloc] init]

sends the init message to an instance of the class MySubClass.

So we call the method -[MySubClass init], passing the instance of the
class MySubClass.

which sends the message init to super, that is, to the same instance of
the class MySubClass, but searching the method -init starting from the
superclass. 

So we call the method -[MyClass init], passing the instance of the
class MySubClass.

This sends the designatedInitializer: message to this instance of the
class MySubClass.

So we search a -designatedInitializer: method starting from the class
MySubClass, and we find -[MySubClass designatedInitializer:]

This sends the message [super init], so we search an -init method from
the superclass and find -[MyClass init], passing the instance of the
class MySubClass.

This sends the designatedInitializer: message to this instance of the
class MySubClass.

So we search a -designatedInitializer: method starting from the class
MySubClass, and we find -[MySubClass designatedInitializer:]

This sends the message [super init], so we search an -init method from
the superclass and find -[MyClass init], passing the instance of the
class MySubClass.

This sends the designatedInitializer: message to this instance of the
class MySubClass.

So we search a -designatedInitializer: method starting from the class
MySubClass, and we find -[MySubClass designatedInitializer:]

This sends the message [super init], so we search an -init method from
the superclass and find -[MyClass init], passing the instance of the
class MySubClass.

This sends the designatedInitializer: message to this instance of the
class MySubClass.

So we search a -designatedInitializer: method starting from the class
MySubClass, and we find -[MySubClass designatedInitializer:]

This sends the message [super init], so we search an -init method from
the superclass and find -[MyClass init],

etc.




The whole point of OOP and inheritance, is to be able send a message to
an object without knowing at compilation time what class or subclass
this object will be.  So the actual method called when we send this
message, is determined at run-time, and may be a method of a subclass
that wasn't even imagined when we wrote this message sending.

When we have:

    @implementation MyClass
    -(id)init{
       return [self designatedInitializer:42]; 
    }
    @end

the only raison-d'être of this method, is to call the method of the
subclass of MyClass of which self is an instance.

Because we know, when we write MyClass, that we don't know what the
future has in stock for us.  We know that the customer will come with
some crazy requirements, which makes -[MyClass designatedInitializer:]
completely inadapted and outdated.

Therefore when the crazy customer comes with his crazy requirements, we
will write a subclass that will do the right thing, by implementing a
-[CrazyCustomerSubclass designatedInitializer:] method, knowing that the
rest of the MyClass code will still work, because everytime it has to
rely on some specific behavior, it will send a message to the object
that will be dispatched to the right method according to the class of
that object.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Back to comp.lang.objective-c | Previous | Next — Previous in thread | Next 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