Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!uw-june!ewan
From: ewan@cs.washington.edu (Ewan Tempero)
Newsgroups: comp.object
Subject: Re: object-oriented this, that, and the other thing
Message-ID: <10013@june.cs.washington.edu>
Date: 30 Nov 89 20:59:13 GMT
References: <2426@umbc3.UMBC.EDU> <190@ark1.nswc.navy.mil> <1561@novavax.UUCP> <76915@linus.UUCP> <984@castle.ed.ac.uk> <1959@tukki.jyu.fi> <1115@castle.ed.ac.uk> <1673@gannet.cl.cam.ac.uk>
Reply-To: ewan@june.cs.washington.edu (Ewan Tempero)
Organization: University of Washington, Computer Science, Seattle
Lines: 59
Fcc: +copy

In article <1673@gannet.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>Dave Berry writes:
[... stuff deleted from both...]
>> So my definition of an OO language would be
>> "classes + dynamic binding of functions".
>> with the footnote that inheritance is required for this in statically 
>> typed languages and damn useful anyway in dynamically typed ones.
>
>GRRRR ...
>
>I wish people would stick to the well established definitions of terms
>like "object-oriented" and not go around inventing new & incompatible 
>ones for no good reason!

While I tend to agree with this sentiment, I also think that the "established
definition" of object-oriented is...misleading. Judging by what I read in
the literature and in this newsgroup, most people think "object-oriented"
means "has classes" and/or "has inheritence" (Wegner didn't help with his
OPSLA'87 paper). Now, as definitions go, this would be perfectly acceptable
if the same people didn't also think that if the language doesn't have these
features then it isn't a good language (and can't have anything to do with
objects) [yes I'm generalizing, but I've met this attitude often enough that
it's worth discussing]

So, let me say what features I think a "good language with objects" should
have. I should warn you that all this is in terms of building and MAINTAINING
large systems.

	(a) Ways to create objects
	(b) Ways to manage objects
	(c) no non-object constucts [ill-defined I know, maybe I'll 
					say something later]

Languages such as C++ and Smalltalk use classes for (a) and (b). C++
fails on (c) [someone claimed that instance variables in Smalltalk can
be referred to directly in a "non-object" like manner..I wasn't sure
what this meant exactly but if true then Smalltalk fails on (c) too]

However classes are the only way to do things. You don't need a class
to create objects--just provide an explict mechanism in the language
(which I'll call an "object constructor") to do this. You don't need
classes to manage the objects either. Afterall, what kind of management
do you want? You basically just want to know what "kind" of object
you've got and what you can do to it. A type system will do this just
fine. Some people will argue that classes are just types. Well that's
partially true, but many people think classes also provide code reuse 
and that's a completely separate mechanism. So I prefer to use "type"
when I mean "describes behaviour" and "class" when I mean "describes
implementation."

If you're uncomfortable with the notion of a language with objects not
providing code reuse [depending on what you mean by code reuse--I'm 
meaning the ability to take pieces of code already written and use
them in building something new without using cut-and-paste in and
editor] then see a paper by Raj and Levy in  ECOOP'89, which describes
how to do software reuse in a language-with-objects that is strongly-typed
and doesn't have classes.

--ewan


Brought to you by Super Global Mega Corp .com