Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!its63b!db
From: db@its63b.ed.ac.uk (D Berry)
Newsgroups: comp.lang.c++
Subject: Re: oo definition request
Message-ID: <1370@its63b.ed.ac.uk>
Date: 20 May 88 14:36:23 GMT
References: <4800024@uiucdcsm>
Reply-To: db@itspna.ed.ac.uk (Dave Berry)
Organization: University of Edinburgh
Lines: 78

In article <4800024@uiucdcsm> grogers@uiucdcsm.cs.uiuc.edu writes:
>
> I disagree with the Wegner definition, since the object's state can be
> manipulated independently of the object.

You also disagree with him in that you think inheritance isn't necessary.

> The major advantage of inheritance is improved code reuse.  I contend that
> in the absence of classes as first class objects inheritance only
> provides code reuse.

I agree.  Code reuse is important, but I believe it's possible to gain the
same effect as inheritance with subtyping and "traditional" scope management.

> It seems to me that an interesting question is: what's the difference between
> abstract data type programming and object oriented programming? I would say
> that the primary difference is polymorphism.  Historically speaking, adts have
> been implemented as hidden data areas with access functions.
>
> Thus, each data type has a set of specific functions for accessing the adt's
> data.  For example: stack_insert( s, item) and queue_insert( q, item).  While
> oo programming assumes polymorphism as implemented through message passing.
> So here we have: s insert: item and q insert: item.  It is the object
> that determines which "insert" method is executed rather than the invoker.

This is not polymorphism; it's overloading function names (and probably dynamic
binding).  A polymorphic function can be applied to an argument of any type
(perhaps of any type in a certain set, but certainly more than one).
Overloading a function name gives you a similar interface, but has one function
for each type.

For example, in ML all lists must contain objects of a single type and the
function "hd" has the type 'a list -> 'a, which means it can be applied to any
list and returns an object of the same type as the objects in the list (it
actually returns the head object of the list).  Thus it is polymorphic.

On the other hand, both "2 + 1" and "2.5 + 1.5" call a function named "+",
but the first calls an integer version and the second a float version.  (In
fact these are defined in their own structures, which are the nearest
equivalent in ML to classes.)

Polymorphism and overloading are similar but different.  The choice obviously
affects code size; it also affects type inference for those languages which
have it.

If ML had subtyping, it might be possible to define polymorphic functions
that would work on objects of a certain type and its subtypes, but not on all
types.  This is similar to inheriatnce in oo langauges.  However, to get
different behaviour for a subclass the function name would have to be
overloaded for that subclass (and often a dynamic binding scheme would have to
be used).

Note: if a language has functions as first class objects then subtyping
is quite different from inheritance.  For example, if "integer" is a subtype
of "real", then a class comprising a function of type "int -> int" could be a
subtype of a class comprising a function "int -> real", but the type makes no
restriction on what the function actually is - for one object of that type the
function could be factorial, for another it could be successor, for a third it
could be abs_value.

The distinction between inheritance and subtyping is similar to the
distinction between polymorphism and overloading.  Inherited functions are
defined for each class rather than for each object, object-oriented
notation notwithstanding.

> While I do think that inheritance and memory management are very useful and
> should be part of any programming environment, I don't think they are
> necessary for oo programming.

I agree (at least for the present).  Consider removing inheritance from
SmallTalk.  Would the result still be object-oriented?  I think so - 
everything in the system would still be an object and evaluation would
still be done by passing messages.

> Greg Rogers
-- 
-------------------------------------------------------------------------------
 Dave Berry.	db%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk	Free jazz, not markets