🚀 go-pugleaf

In article <147@m10ux.UUCP> mnc@m10ux.UUCP writes:
>  This leaves me with two unanswered questions:
>
>(1) What is the difference (other than a rather contrived, anthropomorphic
>    view of the relationship between functions and values), between O-O
>    programming and the ten (?) year old theory and practice called "abstract
>    data types"?  The fundamental belief with technical importance in
>    both methods (with which I completely agree) is that pieces of programs
>    should be divided into chunks that have a precisely documented interaction
>    with other chunks, but the internals of which are completely unknown (or
>    irrelevant to) other chunks.  Put more concisely, "separate WHAT it does,
>    from HOW it does it, so that the HOW can be changed without affecting the
>    WHAT".  Isn't O-O programming simply a special case of, i.e. one particular
>    method for achieving, abstract data types?  It seems to lie completely
>    under the definition of an abstract data type as a collection of types
>    and functions on those types, together with the notion that we can have
>    multiple objects of the abstract data type.

	A.D.T. programming consists of defining some abstract data type,
	which can have some set of operations performed on it -- the set
	of operations and what they do defines the A.D.T.

	O.O. programming consists of definining some objects, which will
	respond to having certain messages sent to them -- the set of
	messages and what the object does with them defines the object.

	So the difference is mainly that of sending a message to an object
	that does the work itself, versus performing an operation upon an
	A.D.T.  The analogy is a good one.

	The advantage/disadvantage to the O.O. languages is that they force 
	you to use this Object/Message paradign all of the time.  The ADT
	programming style is usually a method of using a particular language,
	which does not enforce its use.

>(2) Why is it so hard for O-O programming advocates to explain the advantages
>    of their programming methodology without slipping into obscure, specialized
>    O-O jargon, or invoking the religious argument, "well you can't under-
>    stand why it is better until you've done a large amount of O-O programming
>    yourself"?

	Because other paradigns like ADTs don't present the options that 
	OO programming does, like a formal way of describing general sets
	versus sets of integers where general sets allow operations like
		add( element , set )
		ismember( element , set )
		delete( element , set )
		union( set1, set2 )
		etc.
	and integer sets have all of those but also
		sum( set )
	This sort of thing is easily described with things like "inheritance"
	in object oriented programming ( integer sets are in some sense a
	"descendant" of general sets, and therefore "inherit" the basic 
	operations that general sets allow, etc.)
>Michael Condict		{ihnp4|vax135}!m10ux!mnc
-- 
 Marc Mengel
 ...!ihnp4!cuuxb!mwm