Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!cline
From: cline@cheetah.ece.clarkson.edu (Marshall Cline)
Newsgroups: comp.object
Subject: Re: Types vs. Classes
Message-ID: <CLINE.90Oct1173346@cheetah.ece.clarkson.edu>
Date: 1 Oct 90 21:33:46 GMT
References: <60700001@inmet> <77500058@m.cs.uiuc.edu>
Sender: news@news.clarkson.edu
Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline)
Organization: (I don't speak for the) ECE Dept, Clarkson Univ, Potsdam, NY
Lines: 52
In-Reply-To: johnson@m.cs.uiuc.edu's message of 28 Sep 90 03:14:00 GMT
Nntp-Posting-Host: cheetah.ece.clarkson.edu

In article <77500058@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu writes:
...
>What do we mean when we say that a language is statically typed?
>I could say that this means that programs are type-checked at
>compile-time, not run-time, but this just begs the question, because
>what does type-checking mean?  What are we checking when we check
>types?  Are we checking implementations or specifications?
>
>It seems clear to me that we are checking specifications.  If I
>type-check a Smalltalk expression (x + y) then it means that the
>value of x is an object that understands the + message and that
>the type of the argument of the method that is invoked contains
>the type of y.  I think that the preceeding sentence HAS to use
>the word "type", and that using "class" instead would be very
>counterintuitive.  Thus, it is clear (to me) that "type" means
>specification and that "class" means implementation.
>
>This fits very nicely with the intuition of the Smalltalk
>community.  Everybody knows what I mean when I say that I
>want to type-check Smalltalk.  Some like the idea, some don't
>like it, but everybody knows that I am requiring the values of
>variables to have certain properties, and that I have to write
>down those properties, i.e. specifications.
>
>Ralph Johnson -- University of Illinois at Urbana-Champaign

I concur whole heartedly: a type is a specification, and a class
implements a type.

In C++, a `type' can be simulated by an abstract base class (ABC) with
no representation and with 100% pure virtuals.  Similar constructs in
other strongly typed OOPLs.

Doug Lea and I are presenting a paper at ECOOP/OOPSLA's ``graphical OO
design for software engineering'' (GOOSE) workshop.  The gist of the
paper is that types and classes are different, that types are
specifications, and that *designing* by specifying types *first*, then
by attaching classes to this type scaffolding *afterwards* is
analogous to the architectural-design/detailed-design of the waterfall
model.  Not that we should do them in strict waterfall order in OOP;
they are simply analogous concepts.

Marshall Cline

--
==============================================================================
Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676
cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w
Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600
Career search in progress; ECE faculty; research oriented; will send vita.
PS: If your company is interested in on-site C++/OOD training, drop me a line!
==============================================================================