From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 18 Aug 92 13:57:25 GMT
	<__5mtrq.objsys@netcom.com> <PCG.92Aug14170701@aberdb.aber.ac.uk>
	<1992Aug15.124149.28538@m.cs.uiuc.edu>
	<PCG.92Aug16184526@aberdb.aber.ac.uk> <1992Aug16.212818.29943@m.cs.
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 17 Aug 92 11:44:34 GMT, graham@maths.su.oz.au (Graham Matthews) said:

graham> Could someone provide a concrete example of where seperating
graham> interface and implementation buys one a whole lot,

It's not really about 'buying you a whole lot'; it's that it's
*necessary*, and either it has to be done "properly", or by perverting
language facilities to other ends designed.

graham> or where you want to inherit part of an interface.
			     ^^^^^^^
The seven letter word! :-) Don't use that, it's misleading.

graham> I am not saying that it can't be done or isn't useful, I am
graham> merely interested in an illustrative example.

Well, my favourite example has already been given: deque, stack and
queue.

One can design a general set of components with which one can build a
deque, and then derive queues and stacks from deque.

For example, one possible interface/protocol/signature/... of deque
might be:

	top, bottom	(return the values at one of the two ends)
	push, pop	(operate on the top)
	append, detach	(operate on the bottom)

then that of stack might be:

	deque EXCEPT bottom,append,detach

The same for implementation and specification

Everybody will have noticed that the reverse might be done too; one
builds stack and queue components and merges them to get a deque.

This is however bound to be less useful; it is only by "chance" that
independently designed stack and queue components will fit nicely
together. It usually pays to design the most general 'type' and then
subset it, or enrich it with quite different properties. It then pays to
have symbolic reduction engines as compilers (Turchin's REFAL
supercompiler, many other previous/later ones), as these can efficiently
specialize implementations.

But this looks all pie-in-the-sky! Most languages don't even have
partial application to specialize functions, not to mention
continuations.

Other simple examples that spring to mind are graph/tree, various
varieties of indexing systems (various types of b-trees, of static
indexes, of hashes), various multiple precision number systems, etc.

In general there are many cases where arbitrary algebras on interfaces,
implementations and specifications are useful, and typically:

TOP DOWN
  when there are several denoted type/type denotations that are
  related; mathematicians have the habit, just like programmers, to
  develop algebraic structures by deformation of existing ones.

BOTTOM UP
  when there are complex systems tend to develop over time like
  algebraic structures, by deformation of existing ones; requirements
  change a bit, implementations get extended or rewritten piecemeal, ...

In neither case the deformation is likely to be hierarchical, as some
participant in this discussion would have us believe; the keyword, let
me say, is 'extended subset'. Mix and match, in all the three dimensions
of interface, specification, implementation, seems to be the rule rather
than exception. But maybe, as somebody has remarked, I am not doing
*REAL* OO systems.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.object