Amazon.com Widgets Purpose of -(void) lines in @interface section?
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 22, 2014, 08:40:21 PM
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
|-+ Programming in Objective-C, 4th edition
| |-+ Chapter 3
| | |-+ Purpose of -(void) lines in @interface section?
Pages: [1] Go Down
Print
Author Topic: Purpose of -(void) lines in @interface section? (Read 2757 times)
CMM83
Newbie
*
Posts: 5


Email




on: April 08, 2012, 08:18:40 AM

I noticed in the examples of this chapter I could comment out the -(void) lines in the @interface section and the code would still work fine.  Are those listed in the @interface just for clarity/organizational purposes?  In the @implementation section it seems the same command is basically being done again to declare "n" as an integer argument for the setNumerator method.

Program 3.2 ex:


@interface Fraction: NSObject
{
    int numerator;
    int denominator;
}

// -(void) print;
// -(void) setNumerator: (int) n;
// -(void) setDenominator: (int) d;


@end

_____________________

Just trying to trace through the code line by line and understand what everything's purpose is.  Thanks!
Logged
jonr
Full Member
***
Posts: 142






Reply #1 on: April 10, 2012, 01:52:41 AM

Hmm, interesting, good question.  I just tried this and got the same results as you.  It seems that these method declarations in the @interface section are not required to build and run the program.  As you point out, the corresponding method definitions in the @implementation section provide all the info that the @interface section declarations do (plus more of course, as they provide the actual definitions).  It would be good to find out why these declarations appear to be optional.  Perhaps it is because of the simplicity of this program and for more complicated 'real-world' examples there would be a reason why these are required?
Logged
CMM83
Newbie
*
Posts: 5


Email




Reply #2 on: April 10, 2012, 11:16:26 AM

Thanks for the response.  That's what I'm thinking ... maybe it is just a good coding practice that helps the programmer keep track of the various variables. 

Hmm, also... I remember in the book it said typically in a larger program you'd have the @interface, @implementation, and program sections in separate files ... I wonder if the @interface was broken out into it's own file it it would need those declarations?

Chris
Logged
jonr
Full Member
***
Posts: 142






Reply #3 on: April 10, 2012, 03:11:25 PM

Yeah, good question about the condition where there are separate files.  I hope that someone 'in the know' will clue us in on this.
Logged
Bunchadna
Newbie
*
Posts: 27






Reply #4 on: April 16, 2012, 10:01:23 AM

I noticed the same thing while working through program 6.2.  Here's where I asked the same question
http://classroomm.com/objective-c/index.php?topic=7053.0

And here is seerex's response:

Hi,

glad to see you are experimenting and asking questions :-)

Yes, you can simply just  write the methods in the implementation section with no need to declare them. However, there are certain situations where this wont work, and on top of that, it is poor programming practice.

For instance, sometimes the code-completion feature will not work, as it cannot find a declaration for the method. I believe the true reason has to do with the fact, that method-checks is made at run-time, and not compile time. Thus, the program will run without checking which method belongs where, and simply just send the message to the instance at run time. Luckily it is found and the program works with no error.

However, this approach should not be used UNLESS you are doing it on purpose, which means you want to "Hide" the methods.

This is the actual reason, and will be covered later in the book. The above was something you could relate to, and this here may seem a little strange, but i'll include it for completions sake.

The true reason that it works, is intentional. I am not 100% sure on these concepts as i have yet to fully use them, but this is what i understand: If you don't declare the methods, they are "hidden" and will not get inherited either, thus, they are "local" to the class itself.

However, i have yet to use this form of methods (except 1 time i think), but i think it is the true reason.

However, keep in mind i may be totally off here, and such i am more than happy to be corrected if i provided false information.
Logged
CMM83
Newbie
*
Posts: 5


Email




Reply #5 on: April 21, 2012, 12:50:14 PM

Excellent, thanks for the information!
Logged
sglddy
Newbie
*
Posts: 9


Email




Reply #6 on: April 23, 2012, 12:14:27 AM

Hmmm.  First of all, I'm working under somewhat of a handicap with Xcode 3.1.3 on a Powerbook ppc.  I tried commenting out the method declarations in @interface and it still worked with me, too.  I entered program 3.2 as shown and it did not work until I moved the instance variable declarations to the @interface section. A note on page 33 (Fourth Edition) says that Xcode 4.2 now allows instance variables to be declared in the @implementation section and is considered a better way to declare a class.  Does this mean that the @interface section is being phased out?  I can't try it because of my Xcode version. Anyone try eliminating the @interface section altogether?
Logged
rue
Jr. Member
**
Posts: 53






Reply #7 on: April 23, 2012, 09:00:55 AM

Quote
Does this mean that the @interface section is being phased out?  I can't try it because of my Xcode version. Anyone try eliminating the @interface section altogether?
You get an error if you totally eliminate @interface.
With 4.2, you can either have the variables in the @interface or @implementation.
But the new order from Vatican is we should now move it to the @implementation section to hide the internal variables from prying eyes.
Logged
sglddy
Newbie
*
Posts: 9


Email




Reply #8 on: April 23, 2012, 12:23:58 PM

I think my earlier post was not thought out very well.  The real issue here is inheritance.  Those instance variables and methods that can be inherited are declared in the @interface section.  If they are declared only in the @implementation section, they are considered private and are not inherited by sub-classes.  An important level of control over our data.  So even if it's empty, the @interface section won't go away.  Am I thinking this through a little better?
Logged
rue
Jr. Member
**
Posts: 53






Reply #9 on: April 24, 2012, 08:52:33 AM

sgiddy, I just tried inheritance by creating (BigFraction) classed from Fraction, and it still seems to work. My variables are in the @implementation section.


Code: (Objective-C)
#import <Foundation/Foundation.h>

@interface Fraction : NSObject

@property int numerator;
@property int denominator;

-(void)     print;
-(double)   convertToNum;
-(void)     setTo: (int)n over:(int)d;
-(void)     add: (Fraction *) f;
@end

@interface BigFraction : Fraction
@end

Code: (Objective-C)
#import "Fraction.h"

@implementation Fraction
{
    int numerator;
    int denominator;
}

@synthesize numerator;
@synthesize denominator;

-(void) print {
    NSLog(@"%i/%i",numerator,denominator);
}

-(double) convertToNum {
    if (denominator !=0)
        return (double)numerator/denominator;
    else {
        return NAN;
    }
}

-(void) setTo: (int)n over:(int)d {
    numerator = n;
    denominator = d;
}

-(void) add: (Fraction *) f {
    numerator = (numerator * f.denominator) + (denominator * f.numerator);
    denominator = denominator * f.denominator;
}
@end

@implementation BigFraction: Fraction
@end
Logged
sglddy
Newbie
*
Posts: 9


Email




Reply #10 on: April 24, 2012, 02:46:04 PM

Thanks Rue.  Now I' scratching my head. You didn't show your main() so I have a couple questions.  Did you import only BigFraction, as in: #import "BigFraction.h"? You did not #import "Fraction.h"?  And second, did you alloc/init only using BigFraction, as in: BigFraction *f = [[BigFraction alloc] init];?

I just want to make sure there is absolutely no reference to Fraction in main().

I'm trying to remember where I saw this @interface/inheritance relationship. When I find it I'll let you know. Between the two of us and this remarkable forum, we should figure this out.
Logged
rue
Jr. Member
**
Posts: 53






Reply #11 on: April 24, 2012, 03:02:32 PM

Quote
Did you import only BigFraction, as in: #import "BigFraction.h"?

Being lazy, I defined my BigFraction class in the same Fraction.h/.m files.  So I only had to import Fraction.h in my main program.

But if you created another external file, then yes, you'll also need to import BigFraction.h in your main program.

Quote
did you alloc/init only using BigFraction, as in: BigFraction *f = [[BigFraction alloc] init];?

Well, if you're only using BigFraction, then you'll need *mybigFraction = [BigFraction new];  -- otherwise you'll get an error.

If you also want to use aFraction, then you'll also need aFraction = [Fraction new];

But you don't need to alloc [Fraction new] if your program doesn't need it. Makes sense?

Code: (Objective-C)
#import <Foundation/Foundation.h>
#import "Fraction.h"

int main(int argc, const char * argv[])
{

    @autoreleasepool {
       
       
        BigFraction *mybigFraction = [BigFraction new];
       
       
        // set fraction to 1/4
        [mybigFraction setTo:1 over:2];
       
       
        // display the fraction
        NSLog(@"the contents of mybigFraction is ");
        [mybigFraction print];

    }
    return 0;
}
Logged
sglddy
Newbie
*
Posts: 9


Email




Reply #12 on: April 24, 2012, 03:06:58 PM

Well duh (as my daughter would say), the inheritance issue is the very first section of Chapter 8 (Fourth Edition) "Inheritance".  Reading this and using Program 8.1 should shed some light.  Maybe the great professor can weigh in on this :-) Mr. Kochan?
Logged
sglddy
Newbie
*
Posts: 9


Email




Reply #13 on: April 25, 2012, 03:57:20 AM

Yes, of course, you're right about *mybigFraction = [BigFraction new];, and, yes, it does make sense.  But I still don't understand.  In light of the information in Chapter 8, how can BigFraction inherit the methods from Fraction?  Thank you for helping me rue.  I learned something.
Logged
rue
Jr. Member
**
Posts: 53






Reply #14 on: April 25, 2012, 09:53:23 AM

Quote
how can BigFraction inherit the methods from Fraction?

This magic lines does it all.
Code: (Objective-C)
@interface BigFraction : Fraction  
@end  

@implementation BigFraction: Fraction  
@end  

... in the same way Fraction inherits the methods from NSObject.
Code: (Objective-C)
@interface Fraction : NSObject  
@end

In your code, you can use alloc, init, new - right?  And yet you didn't define those methods for Fraction... where did they came from? from NSObject.  Fraction inherited these from NSObject.  

And since BigFraction inherited methods from Fraction, by the same token, BigFraction also inherited methods from NSObject... that's why you can also use new, alloc, init for BigFraction (even though those methods weren't implemented) 
Last Edit: April 25, 2012, 09:55:32 AM by rue 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.