macOS Hillegass Page 112

[mdeh]

Hi all,
2 questions if I may.

Part of the exercise is to show how KVC coding will use accessors **if** they are present.
To set this up, we write a new init method. ("fido" is an ivar of the class)

-(id) init
{
	[super init];
	[self setValue: [NSNumber numberWithInt: 5] forKey: @"fido"];
		NSNumber *n = [ self valueForKey: @"fido"];
		NSLog(@"Value for \"fido\": %@", n);
		return self;
}

I am thinking this is incorrect, and should be this.

-(id) init
{
	self = [super init];
	if (self)
	{
		NSLog(@"Setting fido to \"5\"");
		[self setValue: [NSNumber numberWithInt: 5] forKey: @"fido"];
		NSNumber *n = [ self valueForKey: @"fido"];
		NSLog(@"Value for \"fido\": %@", n);
		
	}
	
	return self;
}

But...I am betting against Hillegas, so is there a reason why he omits setting the return from super to self?

Then, we write accessors in the standard way, but also add the declaration to the header file for the class, thus.

-(int) fido;
-(void) setFido: (int) n;

Now, again, why are we doing this, when Class AppController is a child of NSObject. The fact that KVC works, does this not assume that fido and setFido already conform to KVC and need not be declared. ( And in fact, the code compiles and runs without declaring these methods without any warnings or errors)

Thanks as usual.

 

[eddietr]

On the first question, the code in the book will work fine (especially since super in this case is just NSObject), but yours is better form.

On the second, what do you mean by "the standard way". You mean using @synthesize?

If so, then you are right the explicit declarations there are not necessary. I don't have the book handy, but maybe the author is introducing different ways to write the accessors and that's why those declarations are there?

 

[mdeh]

On the second, what do you mean by "the standard way". You mean using @synthesize?

If so, then you are right the explicit declarations there are not necessary. I don't have the book handy, but maybe the author is introducing different ways to write the accessors and that's why those declarations are there?

I think perhaps I misunderstood the concept behind KVC. What the book is trying to show is that *if* one is writing custom accessors, then there is a convention that has to be followed ie -key and -setKey. I was confused as to why, if KVC *is* expecting to see this implemented, it still needs a declaration of same. It's not as if KVC is surprised by the signature of the accessors...and I am not trying to be flippant...I am just trying to get my head around this. Does that make sense. So, why does one still need to declare the accessor in the interface, if that is what KVC is expecting to find and use.? Or maybe this is a better question. When one uses alloc and init, you do not have to declare those before using it as it is declared in NSObject. Why not the same for the accessors? Is it simply that **all** methods, whether expected or not, **have** to be declared **somewhere**?

 

[GorillaPaws]

Is it simply that **all** methods, whether expected or not, **have** to be declared **somewhere**?

I'm pretty sure this is why. I'm not certain, but I think it has to do with how the compiler converts methods into selectors and organizes them into the selector table (p. 62-63). I'm guessing that if a method is never declared it's never added to this table and so (even if it's expected) there is no way for the computer to call that method's selector.

 

[eddietr]

I think perhaps I misunderstood the concept behind KVC. What the book is trying to show is that *if* one is writing custom accessors, then there is a convention that has to be followed ie -key and -setKey.

That's right.

I was confused as to why, if KVC *is* expecting to see this implemented, it still needs a declaration of same. It's not as if KVC is surprised by the signature of the accessors...and I am not trying to be flippant...I am just trying to get my head around this. Does that make sense. So, why does one still need to declare the accessor in the interface, if that is what KVC is expecting to find and use.?

So it's not a question of satisfying "KVC", it's a question of satisfying the compiler.

So you could just not declare those methods (just like you could not declare any other method), and your code will still work. The compiler will give you warnings, but the code will still work.

It's just not a good practice, because the compiler can't warn you then if you make a mistake in calling a particular method (wrong number of arguments, for example, or wrong return type). This is generally true for all methods, not just setters and getters.

Or maybe this is a better question. When one uses alloc and init, you do not have to declare those before using it as it is declared in NSObject. Why not the same for the accessors? Is it simply that **all** methods, whether expected or not, **have** to be declared **somewhere**?

All methods *should* be declared (but they don't strictly *have* to be declared). But this is generally true for all methods, not just accessors.

And, yes, things like init are declared at the NSObject level. So your subclass can redefine that method without redeclaring it.

Hope that helps?

 

[mdeh]

Hope that helps?

Yes it does ...and in fact, I was so overwhelmed by this new concept, that I had forgotten that the declaration (for example, in synthesized accessors) is where you would describe attributes such as readonly, readwrite, nonatomic etc. So, once again, thanks.

 

[GorillaPaws]

So you could just not declare those methods (just like you could not declare any other method), and your code will still work.

I never realized that you could not declare your methods and still have your code compile. So now I'm curious, when does the compiler convert your methods to selectors (must be @implementation, right)?

 

[eddietr]

I never realized that you could not declare your methods and still have your code compile. So now I'm curious, when does the compiler convert your methods to selectors (must be @implementation, right)?

Yes, it's part of the compilation process. And yes, it's driving by the method definitions (in the @implementation), not by the method declarations.

Just like you have in C if you're definition doesn't match the declaration, the compiler will complain, but the definition is what really counts.

 

[mdeh]

Yes, it's part of the compilation process. And yes, it's driving by the method definitions (in the @implementation), not by the method declarations.

Just like you have in C if you're definition doesn't match the declaration, the compiler will complain, but the definition is what really counts.

Nice thread here which I just found

http://www.cocoabuilder.com/archive/message/cocoa/2006/5/27/164477