Object Programing and Objective C

[richw at ada-uts.UUCP]

GREAT!  (I'll flame later about some reservations I have).
First of all, I'm extremely glad that someone's pointing out the
benefits of object-oriented programming and C's deficiencies (esp.
naming, as in IPDJMOVE -- arggh!).  Object-oriented programming
pretty much requires the ability to define many different
"add" procedures (as an example) -- naming them add_complex,
add_matrix, etc. in "normal" C is a very limited solution.
(see the end of this note for an example of a better(?) solution).

Does Objective C provide what Smalltalk calls "blocks"?  If so,
I'm even more impressed -- blocks allow one to build sophisticated
control structures, e.g. exception handling (for instance, a message
like "dictionary lookup: key ifNotFound: block").

Nevertheless, I have two reservations about Objective C.
The second, concerning inheritance, is intended to
give another viewpoint on something that, on the surface,
looks wonderful but has its disadvantages.  Expressive
power is an advantage of inheritance, but modularity...

(1) If and when someone implements a production-quality
compiler for Smalltalk (incremental compilers already exist),
it seems Objective C will be, in comparison, a less coherent
jumble of two languages.  While some of the features of C
(e.g. access to very low-level machine details) might be
useful in a Smalltalk, ideally a NEW language would be the
solution -- one with ONLY those features desired (and maybe
borrowed from C and Smalltalk), not the mess that results
from merging two languages.

(2) My second reservation is actually a criticism of inheritance
in general.  While it is very true that data-abstraction helps
improve the modularity of a program, inheritance requires that
a person trying to implement a particular (sub)class need understand
many, if not all, of the details in its chain of superclasses.
That INCLUDES details about the "rep" (representation) of each
superclass, since the rep, or "instance variables", are also
inherited.  "Simple" data abstraction allows rep-details to be
hidden and ignored.  Inheritance detracts from this!

Rather than subclass to extend the functionality of an object,
I think a more modular approach involves implementing the
extension by USING the original object as part of the "rep".

Borrowing a Smalltalk example, rather than make Dictionary a
subclass of Set, have Dictionary include a Set as its one
of its instance variables.  Formerly inherited messages
could be re-implemented with simple one-line procedures
(or "methods", to use Smalltalk terminology).  None of
this requires an inheritance mechanism, but provides a lot
of the same advantages.  Now, if you want to change the
Set's instance variables (rep) without changing its visible
functionality, Dictionary need not be changed at all!
If Dictionary were a subclass of Set, it would have to be
rewritten too.  Thus, subclassing makes Dictionary LESS modular.

At least Objective C doesn't have multiple inheritance. :-)

-- Rich Wagner

P.S.  I'm not alone in these reservations -- a few well-known and
      respected MIT C.S. professors I know feel the same way...

-------------------------------------------------------------------------
/**  Faking data-abstraction in C  **/

static push(stack,obj)
Stack *stack;
Element obj;
{
    .
    .
}

static Element pop(stack)
Stack *stack;
{
    .
    .
}

struct {
    void    (*push)();
    Element (*pop)();
} Stack_Class = { push, pop };

-----------------------------------------------------------------------

A call to one of these stack procedures would then look like

e = (*Stack_Class.pop)(s);

Note this looks somewhat like Ada, except for the (*  ) around the
selector.  It, at least, doubles the number of significant characters
in the name of a procedure.  It also cuts down on the number of
names defined per data-abstraction or class (1 versus X, where X
is the number of procedures defined.  However, this does slow down
procedure calls because of the selection and de-referencing
(ignoring possible compiler optimizations).

I still prefer REAL object-oriented languages...