From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Thu, 13 Aug 92 01:58:32 GMT
Organization: Object Systems
Summary: Type Conformance

In article <PCG.92Aug12205741@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 12 Aug 92 00:33:51 GMT, objsys@netcom.com (Bob Hathaway) said:
>objsys> I would argue strongly for including some form of constraints
>objsys> (in addition to behaviour and/or members) within a type
>objsys> definition.

>Well, I can agree with the sentiment here, but probably the way you
>express it is literally taken a bit incongruous. There is, I am afraid,
>the usual fuzziness as to what the word "type" is intended to mean: a
>denotation, an implementation, a declaration?

Type is well defined.  In ASU's Compilers, type is defined as "the type
of a construct matches that expected by its context" and includes
checking that an operator (and perhaps method) is applied to a compatible
operand(receiver).  No mention is made of implementation since type systems
only deal with types.  Kim and Lochovsky in OO Concepts, Databases and
Applications clearly distinguish between the superficial difference between
type and class and define type purely as specifications.  So "In the presence
of dynamic binding it is (in general) impossible to determine statically the
class of a variable, but with the appropriate type rules we can still perform
type-checking."  They go on to give examples but this sort of definition (as
also quoted from Booch in my last posting) is *so* common I think it already
has been adopted as a standard.  Class (or whatever) defines implementation
and type defines an abstract specification.  

Perhaps this is a clue to the solution of the age old proverb:

	  Why not concrete data types?

Types can be viewed as abstract data types, and classes (or whatever
representational construct) can be viewed as concrete ones!

>Decorating function interfaces and implementations with assertion is a
>very useful technology, whether this be for the purpose of more
>completely describing a type to a human or mechanical reader:

Glad you agree, now you *have* seen a definitive argument on the subject.

>pcg> In cases where they they are needed, writing a specification and
>pcg> getting it right is a hard job.
>
>objsys> How so?  I don't see that its any harder than writing the class
>objsys> specification.  Just define what's required.
>
>It's that "just" that drives one crazy. Writing proper specifications is
>often *harder* than writing the corresponding code, and longer. Formal
>methods have been stymied by this problem for a long time. There have
>been in the past languages in which code was meant to be dully decorated
>by specification, or something similar (Alphard, for example), but they
>have not been a resounding success.

Perhaps we're confusing terminology; it appears to me that writing class
specifications and type specifications are not much different.  Perhaps
you're discussing the greater difficulty posed by creating both kinds of
specifications verses that of creating the class/rep implementation?

>Fortunately decorating functions with small bits of specification does
>help a lot, if one chooses the "right" bits, as you seem to be suggesting.

I think so.  I think multiple inheritance is just fine for trivial
deterministic domains (such as in simple and current information processing)
but conformance with constraints works for the more advanced and more
nondeterministic cases.

>The trouble that many people have is that they don't define their terms
>precisely. The confusion between type as denotation and representation and
>syntax is rampant. Probably you are right to suspect that Booch is not
>very clear about it himself, not just "mortals".

I think Booch's definition is correct but IMHO he blew it by combining the
two in his presentation, hence the real confusion.  Hopefully we
may have cleared up this confusion, at least in this newsgroup.
Type (specification) defines an abstract interface and Class (or whatever
representational/implementation device as appropriate) defines the
concrete structure of an object.

>Again, while I agree with the meaning, some linguistic difference: I
>find slightly disturbing to talk of object type and class. Maybe one
>should say 'type denotation' or semantics instead of 'object type', and
>'type declaration' instead of 'class' (class syntax is just one of the
>possible syntaxes used to declare a type).

No, type and type systems are independent of implementation.  I think this
distinction is very important from both a compiler and applications point
of view.

>objsys> [Minor digression] Also, I've seen some argument in other
>objsys> postings against inheritance and the is-a (or is-a-kind-of)
>objsys> relationship.  You may not like its current form but we
>objsys> certainly use this relationship so ubiquitously in problem
>objsys> solving I'm not sure what you mean; we'd be lost without it and
>objsys> the conceptual understanding of the world it helps provide.
>
>The tragedy with inheritance is that it is unsually constraining. It
>forces unnatural kludges, as above, to do things that should be entirely
>obvious.

This sounds like some particular or common implementation of inheritance
which does not sound fair.

>There is absolutely no reason to believe that structural reuse
>opportunities need to happen in a hierarchical fashion like with
>inheritance. 

Sure there is.  We do it all the time; its called classification.  This
is so obvious I'll assume you're arguing against inheritance as the only
means of information sharing, not that some form of it has no place.

>Once wants the ability (my favourite peeve) to
>independently reuse interfaces, specifications, and implementations, and
>a general purpose algebra for all of thse things.

Some systems with inheritance may not provide this but I don't see
any inherent restrictions.  Sorry I don't have a lot of reference material
around but don't the Jade extensions to Emerald provide inheritance along
with a lot of this?  Another good question: lets define type as an abstract
specification, class as an implementation construct, and abstract class as
an incomplete implementation construct.  To what extent are these constructs
interchangeable?  Can or should types be used as abstract classes?  If so,
should abstract classes exist at all?  Should classes without their
implementations be usable as types (grab their public interface only) to
allow for multiple implementations?  What do you think???

>* given a deque interface, derive stack and queue interfaces by
>_subtracting_ the appropriate elements;

I believe Modula-3 can handle this; there's only theoretical arguments
against it.  You could also include the deque as a member of stack
and queue and simply don't redefine the subtracted interface.  This
should be the preferred solution.

>* given two deque implementations, one with lists and the other with
>resizable arrays, attach one to a stack interface, and one to a queue
>interface;

Given an abstract dequeue class with two implementation classes, List_Dequeue
and Array_Deque, why not derive Stack from List_Dequeue and Queue from
Array_Dequeue.

>* given a specification of a variable size deque, derive from it a fixed
>size deque specification by adding the specification of a size
>constraint;

Just adding a constraint?  Sounds like behavioural inheritance a la DRAGOON.
This may be lacking in most OO notations but I don't see it as a fundemental
flaw in inheritance.  Generics/templates and just passing an argument to the
variable size dequeue could work too.

bob
objsys@netcom.com
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Wed, 19 Aug 1992 10:14:07 GMT
Subject: Re: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Organization: Hewlett-Packard Laboratories, Bristol, UK.