iOS Objective-C question?

[EdChambo]

Hi guys i just started learning Objective-C and i just have a quick question.

heres the program:

#import <Foundation/Foundation.h>

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

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

@end

@implementation Fraction

-(int) numerator
{
	return numerator;
}

-(int) denominator
{
	return denominator;
}

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

-(void) setNumerator: (int) n;
{
	numerator = n;
}

-(void) setDenominator: (int) d;
{
	denominator = d;
}

@end



int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

	Fraction *myFraction = [Fraction new];

	[myFraction setNumerator: 1];
	[myFraction setDenominator: 3];
	
	NSLog (@"The value of myFraction is: %i/%i",
		   [myFraction numerator], [myFraction denominator]);
	[myFraction release];
	
    [pool drain];
    return 0;
}

(got that outa a txt book.)

and my question is: why does

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

have to have the arguments n and d?

couldnt you just put it as :

-(void) setNumerator;
-(void) setDenominator;

????

why does it need those arguments to set the fraction?

 

[balamw]

Do you know any other programing languages or is this your first? (It would help to answer the question if we know more about what is familiar to you).

B

 

[troop231]

why does it need those arguments to set the fraction?

Um, n and d can be anything you want them to be, look at this:

-(void) setDenominator: (int) d;
{
	denominator = d;
}

So that's why they are like that, however you could say denominator = pancakes and it'd still work as long as you declared it earlier. like this:

-(void) setNumerator: (int) n;
-(void) setDenominator: (int) pancakes;

 

[balamw]

If you did that, you'd have to change the implementation to

-(void) setDenominator: (int) pancakes;
{
	denominator = pancakes;
}

No?

B

 

[EdChambo]

Um, n and d can be anything you want them to be, look at this:

-(void) setDenominator: (int) d;
{
	denominator = d;
}

So that's why they are like that, however you could say denominator = pancakes and it'd still work as long as you declared it earlier. like this:

-(void) setNumerator: (int) n;
-(void) setDenominator: (int) pancakes;

my first language.

and i understand that n is just an argument and can be anything... but y do you need it atall y can u just say set denominator:3 y does there need to be the d in there? it just seems pointless?

cus ur making this d then just saying its = to the denominator.... y dont u just say setdenominator and it sets the denominator


yeh im a noob... thats y im here... so i can be not a noob

or pancakes... y do i need that... y cant it just change the denominator?

 

[balamw]

it just seems pointless?

It's not. It's a place holder that lets you do things like:

[aFraction setDenominator: 4];

It lets the computer know that it should expect an integer there and later what to do with it. (assign its value to the denominator of your fraction object).

So, the following code would not be correct because the number there is not an integer.

[aFraction setDenominator: 4.356];

and

[aFraction setDenominator];

also would not be correct since you didn't give an integer.

EDIT: Read the bit under "Method Arguments" in chapter 3 of Kochan's book since that seems to be what you are following.

B

 

[EdChambo]

EDIT: Read the bit under "Method Arguments" in chapter 3 of Kochan's book since that seems to be what you are following.

yeh :L its a good book. i was just confused over this cus it seems u have 2 denominator values 1 as denominator and 1 as d?

It's not. It's a place holder that lets you do things like:

[aFraction setDenominator: 4];

It lets the computer know that it should expect an integer there and later what to do with it. (assign its value to the denominator of your fraction object).

So, the following code would not be correct because the number there is not an integer.

[aFraction setDenominator: 4.356];

and

[aFraction setDenominator];

also would not be correct since you didn't give an integer.

EDIT: Read the bit under "Method Arguments" in chapter 3 of Kochan's book since that seems to be what you are following.

B

i get it ... ima bit stupid :L

how long u rekon it takes before u can wright apps for the app store?

 

[troop231]

If you did that, you'd have to change the implementation to

-(void) setDenominator: (int) pancakes;
{
	denominator = pancakes;
}

No?

B

Yep

 

[chown33]

Yep

Nope.

The following works fine:

@interface Fraction [I]...stuff left out here...[/I]
-(void) setDenominator: (int) pancakes;

@end

@implementation Fraction
[I]...stuff left out here...[/I]
-(void) setDenominator: (int) potrzebie;
{
	denominator = potrzebie;
}

There is no requirement that the parameter names in the @interface match the parameter names in the @implementation.

It will generally make reading the code easier if you don't give senseless names to things, and use a coherent naming approach, but the compiler won't care. It's just a symbol, and the only thing the compiler needs is for it to follow the rules for naming symbols.

 

[troop231]

Nope.

The following works fine: <snip>
There is no requirement that the parameter names in the @interface match the parameter names in the @implementation.

It will generally make reading the code easier if you don't give senseless names to things, and use a coherent naming approach, but the compiler won't care. It's just a symbol, and the only thing the compiler needs is for it to follow the rules for naming symbols.

Right, but I just like it that way for making the code easier to read.

 

[balamw]

There is no requirement that the parameter names in the @interface match the parameter names in the @implementation.

Sorry for the confusion. Perhaps a poor choice of words on my part. I wasn't meaning to imply that the @interface and @implementation needed to match, but that you had to be consistent within the @implementation.

i.e.

@implementation Fraction
-(void) setDenominator: (int) pancakes;
{
	denominator = potrzebie;
}

wouldn't work and I meant that you would need to change potzerbie to pancakes within the implementation.

How would you phrase that properly?

B

 

[chown33]

How would you phrase that properly?

I'm not sure there's a simple answer.

The issue is scope, parts, and consistency within the scope of a particular part. Maybe something like "each part must be self-consistent", but that leaves "part" pretty vague. "Each method must be self-consistent", but the principle applies to more than just methods.

"Each context" is also pretty vague, and hard to pin down because contexts are hierarchical: there is a context in which instance variables are "in scope", and that context continues across all the methods within an @implementation/@end grouping. There's also a "global context" that would encompass any extern variables, class declarations, etc.

 

[balamw]

I'm not sure there's a simple answer.

Glad it's not just me. Or maybe it still is?

B