"Open Implementations and Metaobject Protocols" (was Re: class, prototype, meta)

Bruce Cohen cohenb at gemstone.com
Sun Mar 1 23:36:19 UTC 1998

Regrettably, as far as I can tell the book was never actually
published.  Amazon lists it as hard to find, and the MIT Press web site
lists both the hardback and paper editions as "publication indefinite".
The last time I bugged Gregor about it, sometime late in '96, I think,
he had no idea when (or even if) he would be able to finish the
manuscript.  I understood him to say that much of the work needed to be
re-evaluated in the light of the "aspect-oriented" concepts he was then
working on.  If you're out there Gregor, could you tell us if I'm
correct in this?

Gregor was circulating early drafts to the object community, which may
be why Alan Kay remembers reading a copy.

Let me see if I can give you a quick synopsis of the theme of the book,
based on a couple of conversations with Gregor in '95 and '96, when I
was hoping to use some of the ideas in a project I was working on.  It
didn't happen then, but only because there was no time on my end to
follow through, not because of any flaw in the ideas.

The idea of open implementations is to apply the power of modularization
to complex systems, getting the advantages of encapsulation (simplicity
and reliability of interface, the notion of a contract between the consumer
and the producer, etc.) without the attendant disadvantages (loss of
control over factors that matter to the consumer, like performance in
common use cases).  One good example is a common case in operating
system design: the designer of an OS that manages a fixed-sized pool of
resources, such as disk-cache pages, must make decisions about
resource creation and destruction (e.g., LRU destruction), when the
correct choice often depends on how the application running on the OS
will use those resources.

For instance, when scanning through a file for a given string, you don't
care about a page once you've checked it, but you'd like to have as many
pages as possible read in at once, to maximize the I/O throughput.  On
the other hand, if you're using a dispatch table to send messages, and
hitting the table often, this is an obvious candidate for LRU.

But the typical design of a system that allows the user to configure the
OS at this low a level requires that user to have access to low-level
functions and data, entities that should be hidden from the sight of the
user, for reasons of reliability and security.  A slightly better
approach is used in micro-kernel OS architectures, in which the user can
install one of a number of modules to perform the disk-system function,
each one with a different caching policy.

Open systems are an attempt to go one better, with a disciplined
approach to designing system control interfaces that are orthogonal to
the application programming interfaces, but which allow the application
to specify attributes of the system like performance requirements and
use policies that fit the application's use cases.
"But in our ordinary lives we do not experience the world as a
succession of signifiers any more than we experience it as a succession
of car chases."  Janet H. Murray in "Hamlet on the Holodeck".
Bruce Cohen,                               |  email: cohenb at gemstone.com
GemStone Systems, Inc.                     |  phone: (503)533-3602
20575 NW Von Neumann Drive                 |  fax:   (503)629-8556
Beaverton, OR USA 97006                    |  web:   http://www.gemstone.com

More information about the Squeak-dev mailing list