Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ada-uts.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!ada-uts!richw
From: richw@ada-uts.UUCP
Newsgroups: net.lang.c
Subject: Re: Object Programing and Objective C
Message-ID: <10200024@ada-uts.UUCP>
Date: Fri, 18-Oct-85 16:30:00 EDT
Article-I.D.: ada-uts.10200024
Posted: Fri Oct 18 16:30:00 1985
Date-Received: Tue, 22-Oct-85 05:59:37 EDT
References: <401@aurora.UUCP>
Lines: 45
Nf-ID: #R:aurora:-40100:ada-uts:10200024:000:2329
Nf-From: ada-uts!richw    Oct 18 16:30:00 1985


al:  I called up PPI for Objective C information and they were curious
      about where I heard about it.  Ever consider sales?  :-)

Concerning inheritance hindering modularity because instance variables
are inherited, Keith Gorlen replies:

>> This is not necessarily so.  In some object-oriented languages (e.g.
>> C++) the private instance variables inherited by a subclass are not
>> (normally) accessable from the subclass, except via the superclass's
>> public methods.  Thus, the details of the implementation of a superclass
>> chain are just as hidden to the subclass as they are to any user of
>> the superclass.

Good point.  I guess I misjudged inheritance, assuming inst. var.'s HAD
to be inherited -- as they say, "I stand corrected".

I'm glad that Keith also pointed out that there are least some cases
when it's not clear whether subclassing or use of the abstract object
is better.  This relates to general questions I have about how to
really take advantage of inheritance, i.e. I don't know of any attempts
at coming up with any well-defined methodology for using it.  Can anyone
reference anything, or summarize (if it's possible, in 25 words or less)
a methodology?  For instance, I'd love to learn about ways to really
exploit "abstract superclasses" (as defined in the Smalltalk blue-book);
the times I have have been pretty fruitful, but I personally felt
like I was stumbly in a wilderness...

BTW, anybody have any comments about the incongruity where you can
"dis-inherit" messages/procedures (by overriding
them with procedures that print errors) but cannot dis-inherit
instance variables that, in a certain subclass, lose their usefulness?
You can actually delay "allocation" of instance variables until you
reach the leaves of the class hierarchy, but this leads to a lot
of "subclass responsibilities" (as defined in the Smalltalk-80
blue-book), and a lot of confusion.  Although I again admit that
inheritance CAN be very useful in some circumstances, there have
been situations where I've found myself spending more time wondering
how to structure the class hierarchy than I spent on getting real
work done!  As you can tell, I have this love/hate relationship
with inheritance...

-- Rich Wagner
        (an instance of the multiply-inherited subclass
         of Joseph & Christine Wagner)