A question about class extensions and private methods

[Jon Rossen]

This is a fairly rudimentary question and it really has to do more with
me understanding the book I'm using vs actually understanding the
concept here.

Example: Let's say you have a Fraction class that has methods to
perform simple arithmetic operations on fractions (add, subtract,
multiple, and divide). You also have a reduce method that will reduce
the fractions. You set up your methods that perform the arithmetic to
call the reduce method so that they return the reduced result.

You then decide to create a class extension and move the declaration of
the reduce method into the class extension. The expected result is that
now only the methods in the class have access to the reduce method. The
reduce method now cannot be accessed directly by users of the class.
So, in other words, by placing the reduce method in the class extension
you cannot do something like [myFrac reduce]. The reduce method is only
available for use by the other methods in the class.

I get this, but I'm not understanding how this is being described in my
book.

Here's how the book starts off by describing this:

#1------
'Class extensions are useful, because their methods are private. So, if
you need to write a class that has data and methods that can be used
only within the class itself, a class extension might just fit the bill.'
--------

Then the book gets more specific:
#2--------
'Suppose you only want the methods defined in the implementation section
of the Fraction class to have access to that reduce method, that is you
do not want to make it directly accessible by users of that class. You
could define that method to be private by removing it's declaration from
the original Fraction.h header file....'

Ok, #2 pretty much describes the behavior; pretty simple concept. But is
it just me or is #1 not very accurate or specific in what it's saying?
When it says, 'that can be used only within the class itself', that
seems misleading. Am I correct in that? For instance, a class object
cannot use the method directly, and that object is *within* the class.
e.g. the example I showed: [myFrac reduce] will not work. So, this #1
statement seems a bit vague to the point of being misleading. Am I
misunderstanding what 'within the class itself' means or is the author
not being precise enough here to actually describe the situation accurately?

Thanks for any info.
jonR

[spikeysnack]

The Objective-C runtime makes all methods of a class available at all times.

That being said, the whole philosophy of objc since its beginning has been about organizing data and methods into logical, connected framework.

The message-passing way the runtime connects methods to objects relies on all methods being available at runtime.
You can call any method there is a name for on any class at anytime, and the runtime tries to run the "function" (C-function) associated with that class by that name. If there isn't one, you get some kind of warning or runtime exception.
At compile time you only get a warning, traditionally. Modern objc compilers have switches you can turn on to make warnings errors if you want, but generally the runtime traditionally has just flagged a warning, or if there is a fail-over class for unknown methods the message call can get resent to it for handling.
The traditional way of 'hiding' methods was to not list their signature in the header (@interface) file, but to implement them in the ".m" file.
The idea was that internal methods for developers or internal class use would not get called by users of the class if only headers and binary libraries were distributed. Of course if you have the whole source you can look and find them and call them.

Second
"Class extension" in objc can mean several things. First of course is subclassing a class to add features or tune specifications or override methods of the super class. This works as you might expect, with the added facility that you can call the superclass' method if you want to, and indeed that is actually an idiom in objc for initialization of subclass instances.
calls to self = [[super alloc] init]; in sub class init methods are still around.
The next class extension in objc is called categories.
Categories add or override methods in existing classes. Yes, add methods. Yes, override methods. Yes it can be "unsafe". The programmer simply creates a "mini" header and implementation file containing the new methods with the same class name and the category name in parentheses after. http://rypress.com/tutorials/objective-c/categories
gives good examples.
Lastly is what are actually called "class extensions". Bad name.
They are basically a hybrid of both techniques to achieve "privateness."

You add an extra interface block with an unnamed category "()" to the .m file
and then fill out the method inside the actual class method implementation.

That way it is all defined and implemented inside the main m file and is not
visible when importing the header into other files. C scoping rules apply at compile time and the compiler will choke if it sees a call to the new method
in another file than where it is written. But it is there at runtime as a regular method of the class if you can get a selector for it and call [class performSelector:@sel] on it. But that is what I call meatball surgery, and probably is always a hack, and a "bad idea", and usually leads to a maze of twisty little passages, all different.

There a few older methods of objc that are archaic that restrict what classes in a class heirarchy can perform certain methods such as
subclassResponsibility:_cmd and notImplemented:
but they are not in general use and might act differently on different systems.

The crux of the matter is that objc is sugared-up C. So There are always ways to perform a method if the runtime can find it in its global method list.
performSelector: @sel , objc_message_send(), etc. A programmer that does not have a good knowledge of C should stay out of the runtime's guts, though.

If it's your code and you are writing it for use and not for other programmers to program with, you can call anything you can find, hidden or not.
The protocol system is there to set up rules for calling methods on classes
( err, I mean "sending messages to objects" <cough..>) that makes the compiler warn you if you class doesn't have a method of the name required in the protocol.
Hope that helps a bit.

[Jon Rossen]

Your explanation is great; thanks for your time but you didn't really
answer the SPECIFIC question that I posed; you sort of sidestepped it. I
don't mean to appear ungrateful; I appreciate your input. I wasn't
looking for a treatise on all of this stuff; my book(s) cover it just
fine. You added some useful info, BUT I asked a specific question on
how one of my books explained a specific aspect of this and was asking
feedback on it due to my curiosity. I'm thinking of chucking this book
and getting a different one after running into unclear explanations a
bit too often. Just wanted people's opinion(s) of the explanation the
book gave. I put all that info in my original posting. Thanks.

-jonR