Amazon.com Widgets general clarification (and question regarding initwith)
Welcome, Guest. Please login or register.
Did you miss your activation email?
May 20, 2013, 01:58:18 AM
Home Help Search chat Login Register   
News: Read this please.The Great Kangaroo Escape Looking for reviews of the 4th ed on Amazon!   Twitter:  @skochan
                     

+  Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
|-+  Old Stuff
| |-+  Help!!!
| | |-+  general clarification (and question regarding initwith)
Pages: [1]   Go Down
Print
Author Topic: general clarification (and question regarding initwith)  (Read 2520 times)
dedemike
Newbie
*
Posts: 13






« on: May 07, 2009, 07:56:11 AM »

Dear Steve,

I need some general clarification just to make sure I have it right.  When you make the statement  @interface Fraction: NSObject, you are asking the NSObject root object to form a Fraction class object.  From the Fraction class object, you then generate your Fraction instance objects.  When you write the statement [Fraction alloc], you are sending the Fraction class object the alloc message so it will perform the alloc class method (which it inherited from the root object).  When you then say [newInstanceObject init], you are sending the newInstanceObject a message to perform the instance method init (also inherited from the NSobject root object).

In the initWith example,  the actual code makes sense - I think.  When you say
self = [super init], you are asking the parent class object (in this case NSObject) to
perform its instance method init.  You are assigning the result to self (which is the newly formed object and receiver of the message initWith).  You then of course assign values to the arguments and proceed.  The issue that causes confusion is the issue of overriding.  I believe what your doing here is overriding the NSObject init method - the confusing part is that the method name initWith is obviously different than the method name init.  Are all methods that begin with init... taken
to override the init root method?  The dealloc example made more sense because both methods were named dealloc.

Sorry, the post is so long.  I have really enjoyed your book.  The last computer programming I did was FORTRAN back in the late '80s (showing my age).  I have no previous experience with C or its variants and have learned a great deal.
(Yes, you can teach a somewhat old dog new tricks!  Grin

Thank You,

Michael
Logged
skochan
Administrator
Hero Member
*****
Posts: 3103







« Reply #1 on: May 07, 2009, 08:51:27 AM »

Michael,

Take a look at this thread (and to other forum members, the forum is now getting large enough that you can try a "search" above to locate a topic):

http://classroomm.com/objective-c/index.php?topic=635.0

I think this will answer your question.  If it doesn't let me know!

Cheers,

Steve
« Last Edit: October 30, 2009, 09:18:21 AM by skochan » Logged
dedemike
Newbie
*
Posts: 13






« Reply #2 on: May 07, 2009, 09:26:52 AM »

Steve,

Thanks for the swift reply.  From what I can tell, because you are changing the init  to initwith (overriding the inherited init method), you need to invoke the NSObject    (the "super" in this case) init method within the initWith method.

Also, are the statements in my first paragraph correct?

Thank You,

Michael
Logged
skochan
Administrator
Hero Member
*****
Posts: 3103







« Reply #3 on: May 07, 2009, 11:44:37 AM »

The initWith.. method is not overriding the inherited init method, it is another initialization method to be used instead of the inherited init method.   Because it's being used instead of init, you have to make sure it does whatever the inherited init method would do (which is done by sending the init message to super), and then take care of the additional initialization you want to perform. 

Cheers,

Steve Kochan
Logged
dedemike
Newbie
*
Posts: 13






« Reply #4 on: May 07, 2009, 01:13:17 PM »

Steve,

I think I am getting it.  Let me present another scenario.  Let's say you have Class A, which is a sublcass of the NSObject, and Class B which is a subclass of Class A.  You have the following initwith... statements.

Class A initWithArgumentsForA (contains the self = [super init])
ClassB  initWithArgumentsForB

Both initwith... statements are the designated initializers.

Would the "self = [super ...]" statement for Class B
 be self = [super initwithArgumentsForA] with  the
Class A initWith method  then performing the
self  = [super init]  or would you just put a self = [super init] in the Class B setWith method?

I do understand that the initWith methods are not overriding the inherited
Init method

Sorry for being so tenacious.  I must admit I feel like an "InitWith NitWit"

Michael
Logged
skochan
Administrator
Hero Member
*****
Posts: 3103







« Reply #5 on: May 07, 2009, 02:13:11 PM »

Michael,

Don't feel bad, as this is complicated stuff!

As noted in the text, if your class may be subclassed, then all other initializers in the class should call the designated initializer with default arguments.  That means that if you implement an initWith:... method, and your class may be subclassed, then you should also override the inherited init method in your class to call the initWith:... method.  Any subclass of your class needs to also call the designated initializer of your class, if it's not init. (If there is a designated initializer and you call init in the parent class instead, you can end up with a circular reference).

Read this section from Apple's documentation:

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html#//apple_ref/doc/uid/TP30001163-CH22-SW8

It goes into more detail than I covered in the text.  It may be difficult to follow, but give it a go.

Cheers,

Steve Kochan

Cheers,

Steve Kochan

« Last Edit: November 17, 2009, 04:24:27 AM by skochan » Logged
dedemike
Newbie
*
Posts: 13






« Reply #6 on: May 11, 2009, 08:06:53 AM »

Steve,

Over the past few days I have been studying the apple reference (Thanks).
When you start invoking either init overrides or initWith... statements, you
have to create a chain/ path that leads back to the NSObject init method.
In the example in the book, one could technically write a [self init], however one should avoid getting in to this practice as it increases your likelihood of getting into a circular init.  Sending a message to super avoids this issue.

also, the self = [super init] is the equivalent of object = [object init] in the "main" part of the program. 

Finally, when you start subclassing, the subclass actually overrides the superclass designated initializer and within this overridden method, invoke the subclass designated initializer with a message to self.  The subclass designated initializer then sends a message to the super designated initializer which, through the chain, ultimately leads back to the NSObject init method.  I guess you do the overriding to also minimize your likelihood of getting in to a circular init loop.

The concept of super is a little confusing.  It acts like an object because you can sen a message to it.  However, it does not refer to a specific instance object and does not behave like a class object as it can invoke an instance method.  It seems to mainly be a direction on where to find the appropriate
message.

Is the above true?

Thanks,

Michael
Logged
skochan
Administrator
Hero Member
*****
Posts: 3103







« Reply #7 on: May 11, 2009, 10:00:06 AM »

Michael,

Yes, you really did do your homework!  Excellent, Your analysis is spot-on!   Grin

I'm going to sticky this topic (I may move it into Chapter Study as well) so that everyone can see.

Cheers,

Steve Kochan
Logged
dedemike
Newbie
*
Posts: 13






« Reply #8 on: May 11, 2009, 10:59:31 AM »

Steve,

Thanks for the feedback.  The pictures in the apple reference were truly worth "a thousand words".
You probably know this already, but for others there is some discussion of this in the
NSObject reference material on the apple web site under the init subheading.  BTW - just a minor issue-
the last word in the last paragraph should be "method" and not "message" (even though the message
obviously refers to the corresponding method - just trying to be the most-est correct-est!)

Thanks,

Michael
Logged
Pages: [1]   Go Up
Print
Jump to:  



Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents (c) 2009 classroomM.com. All rights reserved.