NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3183

Internet Message Format | 1992-08-12 | 8.1 KB

Path: sparky!uunet!mcsun!uknet!gdt!aber!aberfa!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Message-ID: <[e-mail]>
Date: 12 Aug 92 20:57:41 GMT
References: <[e-mail]> <[e-mail]>
    <803mb#[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Coleg Prifysgol Cymru
Lines: 166
In-Reply-To: [e-mail]'s message of 12 Aug 92 00: 33:51 GMT
Nntp-Posting-Host: aberdb

On 12 Aug 92 00:33:51 GMT, [e-mail] (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?

Assuming that you refer to the latter two meaning: well, a type/class
declaration usually consists of:

* (implictly) defining construction and deconstruction functions for
  values of that type via type operators; e.g.

    struct complex { float re,im; }

  defines a constructor function (struct complex) and two deconstruction
  functions (complex::re, complex::im). The type operator here is
  'struct'. In most languages type operators are strictly compile time, in
  some (EL/1 most notably) they are run time too.

* (explictly) defining manipulation functions over the values of the
  type, that use the deconstruction interface defined in the declaration.

Now the "constraints" on the type you are talking about are really pre
and post assertions, snippets of specification, in the implicit or
explicitly defined operation on values of that type.

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:

objsys> [ ... ] we have a type in mind and must intelligently check to
objsys> see if various objects can satisfy the description.  There is
objsys> therefore a knowledge base or per-object knowledge to help
objsys> insure correctness and to avoid obvious errors.

Unfortunately:

pcg> In cases where they they are needed, writing a specification and
pcg> getting it right is a hard job.

pcg> How so?  I don't see that its any harder than writing the class
pcg> 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.

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

objsys> I was recently perusing Booch's OO Design book and
objsys> serendipitously ran across the following quote about typing
objsys> where Grady claims that although types and classes are separate,
objsys> he uses the terms interchangeably.

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".


pcg> [ ... ] inheritance, which is a poor way to reuse either protocol
pcg> XOR interface. In most cases separating the two types of reuse is
pcg> fairly difficult.

objsys> [ ... ] highly desirable separation of specification from
objsys> implementation

Ever to be praised! Except that I tend to use 'protocol' or 'interface'
in this context, rather than 'specification'.

To me a specification is a description of a type denotation, not of the
protocol used to access the implementation of the type.

  If I have understood correctly that you referring to the syntactic
  specification of a type/class, that is its protocol/interface.  I once
  had on these screens a slightly similar discussion, in which it turned
  out that 'specification' tends to be used somewhat differently in the
  USA and in Europe. The European custom, which I use, is that
  'specification' is the description of the semantics, while the USA
  custom is that 'specification' is the description of the interface.

This distinction between specification/semantics and protocol/interface
to me is essential, as there can be types alternative interfaces for
types with the same denotation, or two types with different
specification can have the same interface.

objsys> [See the Emerald paper for a quick discussion on this].

There is some of this in Modula-3 too.

objsys> [ ... ] the separation both more powerful and more flexible than
objsys> the result of combining object type and class.  And I also believe
objsys> it simplifies programs by *not* confusing the two and hence by
objsys> *not* confusing the software engineer.

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).

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. Program modules can be described independently in one of three
dimensions, the implementation, the specification, the interface. Now In
theory programming should be done like this:

    The problem domain is surveyed; data design is done, algorithm
    design is done. Interfaces are defined, implementations are
    coded.  Identification of structural reuse opportunities
    are identified in all three domains.

There is absolutely no reason to believe that structural reuse
opportunities need to happen in a hierarchical fashion like with
inheritance. Once wants the ability (my favourite peeve) to
independently reuse interfaces, specifications, and implementations, and
a general purpose algebra for all of thse things.

For example:

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

* 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 a specification of a variable size deque, derive from it a fixed
size deque specification by adding the specification of a size
constraint;

and so on. It is clear that IS-A/HAS-A and other inheritance based
relationships really don't provide a sound conceptual basis for all the
work above, both because they are too hierarchical and because their
level is often not clear (interface, implementation or specification?);
for example IS-A/HAS-A usually are meaningfully applied only in the
domain of specification, and really don't work in the interface or
specification domains.

objsys> Smalltalk does have virtual classes; just don't implement a
objsys> method and you've got them.

Kludge, kludge. :-) One should aim to describe explicitly things in a
program text, not leave in the absence of method bodies the important
information that this class declaration is really meant to be an
interface specification.
--
Piercarlo Grandi                   | JNET: [e-mail]
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: [e-mail]