macOS New to Objective-C, a few newbie questions if you dont mind :)

[s4yunkim]

Just starting to learn Objective-C... it hurts my head but it's fun at the same time, so I guess it's not too bad.

I just started on a section of a book about the OOP part of Objective-C, and I had two questions:

1. It says in the book that:

The definitions of the individual methods are next. They don’t have to appear in the same order as they do in the @interface directive. You can even define methods in an @implementation that don’t have a corresponding declaration in the @interface. You can think of these as private methods, used just in the implementation of the class.

NOTE
You might think that defining a method solely in the @implementation directive makes it inacces- sible from outside the implementation, but that’s not the case. Objective-C doesn’t really have private methods. There is no way to mark a method as being private and preventing other code from calling it. This is a side effect of Objective-C’s dynamic nature.

If that's true, why is it necessary to do the @interface part at all?



2. Also, I notice that in the sample code, they do this:

- (void) setFillColor: (ShapeColor) c
{

     fillColor = c;

} // setFillColor

They do this for other parts of the implementation(?) as well, but the variable "c" is "b", "a", and so on. I understand that this is done as to not cut off the scope of the old variable, but does it matter if the variable I use is the same as another part of the implementation?

For example:

- (void) setFillColor: (ShapeColor) c
{

     fillColor = c;

} // setFillColor





- (void) setBorderColor: (BorderColor) c
{

     borderColor = c;

} // setBorderColor

What problems would be caused by this?




Thank you in advance for your help

 

[jiminaus]

If that's true, why is it necessary to do the @interface part at all?

So objects of other classes can "call" those methods of objects of the class being declared/defined. You should see the necessity for this once you start defining more than one class and objects for those classes start communicating with each other.

I understand that this is done as to not cut off the scope of the old variable, but does it matter if the variable I use is the same as another part of the implementation?

For example:

- (void) setFillColor: (ShapeColor) c
{

     fillColor = c;

} // setFillColor

- setBorderColor: (BorderColor) c
{

     borderColor = c;

} // setBorderColor

What problems would be caused by this?

There's no problem with this at all.

The first c's scope starts at opening brace of setFillColor and ends at the closing brace of setFillColor. The scope of the second c starts at the opening brace of setBorderColor and end at the closing brace. This is, each c is local to their respective methods.

They are completely different and separate c's. They have no relation to each other; except they have the same name, but that's only a similarity detected by us humans, to the compiler there is no similarity at all.

 

[s4yunkim]

So objects of other classes can "call" those methods of objects of the class being declared/defined. You should see the necessity for this once you start defining more than one class and objects for those classes start communicating with each other.



There's no problem with this at all.

The first c's scope starts at opening brace of setFillColor and ends at the closing brace of setFillColor. The scope of the second c starts at the opening brace of setBorderColor and end at the closing brace. This is, each c is local to their respective methods.

They are completely different and separate c's. They have no relation to each other; except they have the same name, but that's only a similarity detected by us humans, to the compiler there is no similarity at all.

That clears it up. Thank you for your great answers!