ncjuul@freja.diku.dk (Niels Christian Juul) (07/21/89)
Dear fellow-netters.
This bibliography contains the Proceedings of the European Conference on
Object-Oriented Programming (ECOOP'89).
The format is bibtex, with the inclusion of two extra field-names:
'Class' gives keywords for the article.
'Abstract' gives an abstract of the article.
Remove anything before the CUT-line, and any traillings, after the TUC-line.
--Niels Chr.
-------------------------- > C U T here < ----------------------
% File: Bibliography/ecoop89.bib
% Proceedings of ECOOP'89 European Conference on Object-Oriented Programming.
% Compiled by Niels Christian Juul, DIKU, Denmark, 89.07.21.
%
% Though throughfull proof-readings has been done, no warrenty is given that
% contents of this document is complete correct (neither should it be
% complete incorrect).
%
% Macro defs.:
% ============
@string{ ecoop89 = "{ECOOP'89} {P}roceedings of the 1989 {E}uropean
{C}onference on {O}bject-{O}riented {P}rogramming" }
@string{ bcsws = "{B}ritish {C}omputer {S}ociety {W}orkshop {S}eries" }
%
% Bib.items
% ==========
%
% The books containing the 1st, 2nd and 3rd ECOOP proceedings,
% ie. for the years 1987, 1988 and 1989:
%
@proceedings(ECOOP87,
Key = "ECOOP'87",
Editor = "J. B\'{e}zivin and J.-M. Hullot and P. Cointe and
H. Lieberman",
Title = "ECOOP'87,
European Conference on Object-Oriented Programming,
Proceedings,
Lecture Notes in Computer Science, Volume 276",
Year = 1987,
Publisher = "Springer-Verlag",
Abstract = "Conference held the 15--17 June 1987 in
Paris, France.
Proceedings contains 23 refereed
and 2 invited papers"
)
@proceedings(ECOOP88,
Key = "ECOOP'88",
Editor = "S. Gjessing and K. Nygaard",
Title = "ECOOP'88,
European Conference on Object-Oriented Programming,
Proceedings,
Lecture Notes in Computer Science, Volume 322",
Year = 1988,
Publisher = "Springer-Verlag",
Abstract = "Conference held the 15--17 August 1988
in Oslo, Norway.
Proceedings contains 22 refereed (selected from 103)
and 1 invited papers"
)
@proceedings(ECOOP89,
Key = "ECOOP'89",
Editor = "Stephen Cook",
Title = "{ECOOP'89}, Proceedings of the 1989 {E}uropean
{C}onference on {O}bject-{O}riented {P}rogramming,
{B}ritish {C}omputer {S}ociety {W}orkshop
{S}eries",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Abstract = "Conference held the 10--14 July 1989 at
East Midland Conference Centre,
University of Nottingham, England.
Proceedings contains 21 refereed (selected from 90)
and 2 invited papers"
)
%
% The contents of the 1989 Proceeding (ECOOP'89):
%
@inproceedings(ECOOP89:Raj,
Key = "Raj and Levy",
Author = "Rajendra K. Raj and Henry M. Levy",
Title = "{A {C}ompositional {M}odel for {S}oftware {R}euse}",
Pages = "3--24",
Institution = "Department of Computer Science, FR-35,
University of Washington, Seattle, Washington",
Booktitle = ecoop89,
Month = jul,
Year = 1989,
Editor = "Stephen Cook",
Publisher = "Cambridge University Press",
Organization = bcsws,
Abstract = "Emerald is a strongly-typed object-oriented
language designed for programming distributed
applications. Among other things, it provides
abstract typing, type conformaty, and complete
seperation of type from implementation. While
Emerald supports type inheritance, it does not
support behavior sharing among objects for
simplifying distribution. To increase Emerald's
utility in general-purpose programming, some
support for software reuse is needed. Our research
reveals that inheritance-based techniques commonly
used in other object-oriented systems for obtaining
reuse are inappropriate for Emerald. As an
alternative to traditional inheritance, a
compositional model, in which objects are composed
from simpler entities, is proposed, outlined and
analyzed in this paper.",
Class = "conformaty, inheritance, reuse, composition,
Emerald, Jade"
)
@inproceedings(ECOOP89:Taenzer,
Key = "Taenzer Ganti and Podar",
Author = "David Taenzer and Murthy Ganti and Sunil Podar",
Title = "Problems in Object-Oriented Software Reuse",
Pages = "25--38",
Institution = "U S WEST Advanced Technologies",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper discusses problems in object-oriented
software reuse and tools that can be used to help
alleviate these problems. Two approaches to software
reuse in object-oriented programming enviroments are
presented: {\em construction} and {\em subclassing}.
We have identified an inter-class dependency which
seems to cause problems during the creation of
new subclasses. This issue, which we call the
{\em yoyo} problem, is related to objects sending
themselves messages which may cause the execution
of methods up and down the class hierarchy.
Tools we have build to help with these problems are
described.",
Class = "inheritance, reuse, subclassing, self,
enviroment, Objective-C"
)
@inproceedings(ECOOP89:Sakkinen,
Key = "Sakkinen",
Author = "Markku Sakkinen",
Title = "Disciplined Inheritance",
Pages = "39--56",
Institution = "{University of Jyv\"{a}skyyl\"{a}},
Department of Computer Science, Finland",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Several other properties of objects are regarded as
more important than inheritance. Inheritance is
classified into two alternatives: {\em insidential}
and {\em essential}. Incidential inheritance is a
matter of implementation and software engineering,
and should be completely encapsulated. Essential
inheritance models important relationships in the
problem domain, and should be completely vissible.
It is then attempted to model inheritance in terms
of aggregation and dependence. A number of omissions
and divergences and some surprising parallels are
found in the treatment of inheritance in existing
object-oriented languages and previous literature.
This contribution does not pretend to close the
case yet: for instance, intermediate forms between
purely incidential and purely essential inheritance
are not discussed.",
Class = "inheritance, encapsulation, complex objects, type,
compability, delegation, programming discipline,
class design"
)
@inproceedings(ECOOP89:Cook,
Key = "Cook",
Author = "William R. Cook",
Title = "A Proposal for Making Eiffel Type-safe",
Pages = "57--70",
Institution = "Hewlett-Packard Laboratories, Palo Alto, USA.",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Statically type-correct Eiffel programs may produce
run-time errors of several reasons. 1) Attributes
may be redeclared during inheritance, invalidating
assignments in the superclass. 2) A formal method
argument type may be restricted in violation of the
contravariance of function types.
3) Two applications of a generic class are assumed
to conform if the actual arguments conform. The
third problem is solved by case analysis on the
variance of generic parameters. Declaration by
association provides a solution to the first two
problems, but suffers from additional difficulties.
{\em Type attributes}, or generic parameters with
default values, are suggested as a replacement for
most cases of declaration by association. The
special association type used to express type
recursion cannot be explained using type attributes,
and it appears to be a truly novel construct for
typing object-oriented programs. One consequence
of this construct is that Eiffel's conformance
hierarchy is a proper subset of its inheritance
hierarchy.",
Class = "conformance, inheritance, class, type, superclass,
covariance, contravariance, generic, Eiffel"
)
@inproceedings(ECOOP89:Deutsch,
Key = "Deutsch",
Author = "L. Peter Deutsch",
Title = "The Past, Present and Future of Smalltalk",
Pages = "73--87",
Institution = "ParcPlace Systems",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Smalltalk has firmly established itself as a
contributer to software technology, a practically
useful application development enviroment, and a
participant in the commercial marketplace.
This paper reviews its evolution, survey its current
roles, and offers some opinions about its future.
",
Class = "history, future, programming enviroment, Smalltalk"
)
@inproceedings(ECOOP89:Yokote,
Key = "Yokote, Teraoka and Tokoro",
Author = "Yasuhiko Yokote and Fumio Teraoka and
Mario Tokoro",
Title = "A Reflective Architecture for an Object-Oriented
Distributed Operating System",
Pages = "89--106",
Institution = "Sony Computer Science Laboratori Inc., Japan",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper proposes the Muse object model
which provides a reflective architecture
for an object--oriented distributed operating
system. The model makes a clear
distinction between meta hierarchy and class
hierarchy. It provides an inheritance mechanism for
programming/compile--time facility and a delegation
mechanism for run--time facility. It also helps to
manage physical resources which are indispensable
in describing operating systems. The paper also
describes the structure of the Muse operating
systems which is being implemented
based on the Muse object model.",
Class = "reflective, distributed operating system,
inheritance, class, meta hierarchy, model, Muse"
)
@inproceedings(ECOOP89:Briot,
Key = "Briot",
Author = "Jean-Pierre Briot",
Title = "Actalk: a Testbed for Classifying and Designing
Actor Languages in the Smalltalk-80 Enviroment",
Pages = "109--129",
Institution = "Equipe Mixte LITP - RXF, Universit\'{e} Pierre et
Maie Curie, Paris, France",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper discribes a system for designing and
classifying actor languages. The system, named {\it
Actalk}, is based on a minimal kernel
introducing actors into Smalltalk--80.
The Actalk kernel extends passive and
sequential objects activated by synchronous messages
passing into active and concurrent actors
communicating by asynchronous messages
passing. This defines a sub--world
of actors embedded into the Smalltalk--80
programming language and environment, which is
left unchanged. The Actalk kernel is composed of
only two Smalltalk--80 classes. Simulating
current actor languages or designing
new ones is achieved by defining subclasses of
these two kernel classes. All such
extensions are implicitly classified by the
inheritance mechanism and unified into the Actalk
enviroment. We are currently extending the standard
Smaltalk--80 programming environment to design a
specific one dedicated to Actalk concurrent
actors.\\
The motivations and the goals which
led to design the Actalk system are first discussed.
Then the structure and implementation of the kernel
of Actalk is detailed. The very good integration of
this kernel into the Smalltalk--80 programming
language and the enviroment is demonstrated through
some examples. Interests and limits of combining
objects with actors are then discussed. In the last
part of the paper, we demonstrate
the expressive power of the Actalk kernel by
extending it to simulate the two main actor
computation models and programming languages,
namely, the Actor model of computation, and the
Abcl/1 programming language.",
Class = "object, concurrency, actor, kernel, integration,
modularity, combination, classification,
enviroment, simulation, Smalltalk-80,
ConcurrentSmalltalk, Act*, Abcl/1"
)
@inproceedings(ECOOP89:Kafura,
Key = "Kafura and Lee",
Author = "Dennis G. Kafura and Keung Hae Lee",
Title = "Inheritance in Actor Based Concurrent
Object-Oriented Languages",
Pages = "131--145",
Institution = "Department of Computer Science, Virginia Tech.
Blacksburg, Virginia, USA",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Inheritance is a valuable mechanism which enhances
reusability and maintainability of software.
A language design based on the actor model of
concurrent computation faces a serious problem
arising from the interference between concurrency
and inheritance. A similar problem also occurs
in other concurrent object--oriented languages.
The problems found in existing concurrent
object--oriented languages are described, and a
solution based on a concept called behavior
abstraction is presented.",
Class = "real-time, reuse, open interface, actor,
concurrency, inheritance, behavior abstraction"
)
@inproceedings(ECOOP89:Kaiser,
Key = "Kaiser, Popovich, Hseush and Wu",
Author = "Gail E. Kaiser and Steven S. Popovich and
Wenwey Hseush and Shyhtsun Felix Wu",
Title = "{MELD}ing Multiple Granularities of Parallelism",
Pages = "147--166",
Institution = "Columbia University",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Programming language design for parallel and/or
distributed systems typically follows one of three
approaches. The first is to parallelize and/or distribute
conventional sequential languages such as Fortran, C and
Lisp {\it via} a parallelizing compiler and remote
procedure call. The second approach is to add concurrent
constructs to what is fundamentally a sequential
language, as was done for Ada, Argus, Avalon
and Modula--2. The third is to design a fundamentally
concurrent language, as has been done for
ConcurrentSmalltalk, Emerald, Mentat and SISAL.
These approaches add a nice
set of facilities for one style of concurrent programming
while ignoring other styles. We are developing a
concurrent programming language, MELD, that supports a
range of concurrent styles by supporting multiple
programming paradigms at multiple levels of granularity.
MELD integrates four paradigms: 1) Object--oriented, with
encapsulated classes, multiple inheritance and active
objects. 2) Macro dataflow, where the ''macro''
implies the dataflow is at the source code level - among
statements - rather than the machine level. 3) Module
interconnection, with modular units called {\it features}
that bundle together related classes and exports classes
for use by other features. 4) Transaction processing, for
fault-tolerance and concurrency control within
applications and among users.\\
First we give a brief overview of the language, ignoring
concurrency issues. Then we describe how MELD integrates
several granularities of parallelism, in particular,
cuncurrency among users, among objects, among methods and
among statements. We compare MELD to a number of other
concurrent object--oriented programming systems, and
briefly describe the implementation. We conclude by
summarizing our contributions. The appendix gives a small
demonstration program.",
Class = "multiple inheritance, concurrency, modules,
features, parallellism, Meld"
)
@inproceedings(ECOOP89:Dixon,
Key = "Dixon",
Author = "G. N. Dixon and G. D. Parrington and
S. K. Shrivastava and S. M. Wheater",
Title = "The Treatment of Persistent Objects in Arjuna",
Pages = "169--189",
Institution = "Computing Laboratory, University of Newcastle upon
Tyne, UK",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "{\it Arjuna} is a programming system which provides
a set of tools for constructing fault--tolerant
distributed applications. It supports an
object--oriented model of omputation in which
atomic actions (atomic transactions)
control sequences of operations invoked upon
persistent objects. Persistent objects outlive the
applications that create them and this paper
concentrates on the mechanisms within {\it Arjuna}
that are concerned with their management.
The paper describes how these
mechanisms are related to the other {\it Arjuna}
mechanisms required by atomic actions for the
distribution, concurrency control, recovery and
commitment of persistent objects.",
Class = "atomic transaction, persistency, fault-tolerant,
distribution, C++, Arjuna"
)
@inproceedings(ECOOP89:Shapiro,
Key = "Shapiro, Gautron and Mosseri",
Author = "Marc Shapiro and Philippe Gautron and
Laurence Mosseri",
Title = "Persistence and Migration for C++ Objects",
Pages = "191--204",
Institution = "INRIA, France",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "We describe the support to object management of the
distributed object--oriented operating system SOS. We
discuss the integration of object migration and storage
into C++ programs, a language not designed for that
purpose. The necessary support is split between the
compiler and a run--time object management system.
Migration and storage preserve the type and structure of
the objects, which may be user--defined and arbitrarily
complex.\\
Our mechanisms are simple, generic, and require little
programmer intervention. The key elements are dynamic
classes, a generalized pointer type which allows to
efficiently refer to an object, pre--requisite objects,
and a mechanism for object re--initialization.",
Class = "persistency, migration, dynamic linking, dynamic
type-checking, object-oriented operating system,
C++, SOS"
)
@inproceedings(ECOOP89:Kahn,
Key = "Kahn",
Author = "Kenneth M. Kahn",
Title = "Objects --- A Fresh Look",
Pages = "207--223",
Institution = "Xerox PARC, USA",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Actors and object--oriented programming have survived for
about twenty years without significant changes in the
basic conception of what an object or actor is. Looking
at object--oriented programming from the concurrent logic
programming framework leads one to question the very
basic assumptions of objecthood. Need there be only
a single port through which all messages to an
object arrive? Or can there be several input ports
corresponding to different capabilities or viewpoints?
When a message is put on a port why can't there be
more than one listener jointly reacting? What is the
identity of an object and why do we think it persists over
time? Would it be useful to be able to transfer
communication ports? Perhaps a busy object should be able
to clone itself and share the incoming requests and later
rejoin.\\
All of these ways of stretching the notion of objecthood
are expressible in a straight--forward and natural manner
in concurrent logic programming languages. Concurrent
logic programming techniques have been developed and are
in common use which exploit these extra degrees of
freedom. These techniques are presented along with a
discussion of their importance and utility. The lesson
which I hope object--oriented programmers will draw from
this paper is that there is novel, relevant, and useful
research going on in the concurrent logic programming
community.",
Class = "logic, actors, port, object identity, concurrent
logic programming"
)
@inproceedings(ECOOP89:Pun,
Key = "Pun and Winder",
Author = "Winnie W. Y. Pun and Russel L. Winder",
Title = "A Design Method For Object-Oriented Programming",
Pages = "225--240",
Institution = "Department of Computer Science, University
College London, England",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper describes the primary framework of a
design method targeted at object--oriented programming. The
design method is not a revolutionary one but adopts
appropriate ideas and graphical constructs from existing
design methods. It is specially tailored to the
characteristic features of object--oriented programming
languages. This paper mainly discusses the structure and
some of the preliminary ideas of the design method.",
Class = "design methods, structure chart, inheritance,
design layer"
)
@inproceedings(ECOOP89:Attardi,
Key = "Attardi, Bonini, Boscotrecase, Flagella, Gaspari",
Author = "Guiseppe Attardi and Cinzia Bonini and Maria
Rosaria Boscotrecase and Tito Flagella and
Mauro Gaspari",
Title = "Metalevel Programming in CLOS",
Pages = "243--257",
Institution = "Artificial Intelligence Division, DELPHI SpA,
Italy",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "The facilities of the Metaobject Protocol are
explored to incorporate various paradigms of
object--oriented programming within the Common
Lisp Object System (CLOS). The basic principles
of metalevel programming are sketched and
the technique is applied to develop atomic objects,
persistent objects and graphic objects for CLOS.",
Class = "metaobject, atomic objects, persistency,
inheritance, CLOS"
)
@inproceedings(ECOOP89:Malenfant,
Key = "Malanfant, Lapalme and Vaucher",
Author = "Jacques Malanfant and Guy Lapalme and Jean Vaucher",
Title = "{ObjVProlog:} Metaclasses in Logic",
Pages = "257--269",
Institution = "Laboratoire INCOGNITO, Universit\'{e} de
Montr\'{e}al, Canada",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper presents an extension of logic
programming towards object--oriented programming
through the adaption of the {ObjVLisp} model to
Prolog. The resulting system is called {ObjVProlog},
which provides metaclasses and unifies
metaclass/class/instance concepts in a systematic
and reflective way. The {ObjVProlog} system and its
implementation are described. Metaclasses are
shown to be a very powerful tool. In this paper,
we use them in an object--oriented way to develop
a {\it part-whole hierarchy} and also for logic
programming to define objects that behave like
expert systems. Several other potential uses
are discussed: faster objects, parallelism, object
versions with virtual copy mechanisms and
objects with a specialized logic.",
Class = "logic programming, metaclasses, meta-programming,
reflective, part-whole hierarchy, ObjVProlog,
ObjVLisp"
)
@inproceedings(ECOOP89:Mueller,
Key = "Mueller and {Pr\"{o}frock}",
Author = "Gerhard {{M\"{u}ller}} and
Anna-Kristin {Pr\"{o}frock}",
Title = "Four Steps and a Rest in Putting an Object-Oriented
Programming Enviroment to Practical Use",
Pages = "271--282",
Institution = "Nixdorf Software Engineering GmbH, F.R. Germany",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "Designing and developing an object--oriented
programming enviroment is an exciting task.
Putting it into practice is a different matter
entirely. We did both. This paper reports on
the achievements and setbacks encountered in
putting A.S.E., an object--oriented programming language
and associated enviroment, to practical use in
application software development projects. Although the
experience outlined is based on a limited number of
projects of various sizes, it might be expected that
object--oriented programming is well--suited for
modelling a wide class of applications problems. The
authors conclude that as increasing use is made of the
object--oriented approach, so too will the traditional
development cycle see major changes which will not only
bring forth better applications, but also lead to
problems in moving traditional programmers into the
object--oriented world.",
Class = "programming enviroment, development style,
experience, A.S.E."
)
@inproceedings(ECOOP89:Gamma,
Key = "Gamma, Weinand and Marty",
Author = "Erich Gamma and {Andr\'{e}} Weinand and Rudolf
Marty",
Title = "Integration of a Programming Enviroment into
ET++ --- A Case Study",
Pages = "283--297",
Institution = "Institut {f\'{u}r} Informatik, University of
{Z\"{u}rich}, Switzerland",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "ET++ is an object--oriented application
framework designed to provide a
foundation for interactive graphic applications
with a consistent user
interface. ET++ is implemented in C++ and runs
under UNIX and SunWindows or the
X11 window system. This paper
presents a case study of the integration of a
programming environment consisting
of an {\it inspector}, a {\it class
browser}, and a {\it hierarchy viewer}
into ET++ based on an extended runtime
support for C++. As an enhancement
of the programming environment a prototype
of a {\it hypertext cookbook}
illustrating the application building process
with ET++ is briefly discussed.
The paper also includes a discription of the
basic functionally of ET++ and a
discussion of the design and implementation of
the programming environment.
Emphasis is put on the benefits of using an
object--oriented application framework.",
Class = "application framework, user interface, run-time
support, programming enviroment, teaching, C++,
ET++"
)
@inproceedings(ECOOP89:Friedrich,
Key = "Friedrich, {H\"{o}llinger}, Stary and Stumptner",
Author = "Gerhard Friedrich and Wolfgang {H\"{o}llinger} and
Christian Stary and Markus Stumptner",
Title = "{ObjView:} A Task-Oriented, Graphics-Based Tool for
Object Visualization and Arrangement",
Pages = "299--310",
Institution = "Technical University of
Vienna, Austria",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "The {ObjView} tool provides interactive,
graphics--based access to object,
relationship and methods, supporting
the varied activities of designing
components for automatic routing systems.
The visualization uses a
object--oriented representation of
complex technical systems including context
specific information (attributes,
methods, etc.) which encourages users to
manipulate and view parts of the
system in a modular fashion. It supports
navigation along physical and
functional object relationships, as well as
direct selection of objects from a
graphical representation of the internal
system model. A preliminary version of
the application has been implemented to
demonstrate the functional and
organization features of the user
interface.",
Class = "visualization, user interface, automatic routing,
ObjView"
)
@inproceedings(ECOOP89:Madany,
Key = "Madavy, Campbell, Russo and Leyens",
Author = "Peter W. Madavy and Roy H. Campbell and Vincent F.
Russo and Douglas E. Leyens",
Title = "A Class Hierarchy for Building Stream-Oriented File
Systems",
Pages = "311--328",
Institution = "University of Illinois at Urbane-Champaign, USA",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper describes the object--oriented
design and implementation of a family
of stream--oriented file systems under UNIX
and under an object--oriented
operating system called {\it Choices}.
A class hierarchy provides an
object--oriented taxonomy of the algorithms
and data structures used in the
design of this family. The family includes
the System V file system, the 4.2
BSD file system, and the MS--DOS file system.
The class hierarchy has been developed by a
series of experiments that are
designed to lead to a framework for
object--oriented file systems. The class
hierarchy for stream--oriented file systems
is the product of the second
experiment in this series in which we
revised a class hierarchy for UNIX--like
file systems to include the MS--DOS file system.
We describe the hierarchy, how it evolved
from the first experiment to the second,
and review the lessons that we
have learned from the two experiments.",
Class = "object-oriented file system, stream-oriented file
system, class hierarchy, inheritance, C++, Choices"
)
@inproceedings(ECOOP89:Hedin,
Key = "Hedin",
Author = "{G\"{o}rel} Hedin",
Title = "An Object-Oriented Notation for Attribute Grammers",
Pages = "329--345",
Institution = "Department of Computer Science, Lund University,
Sweden",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "This paper presents an attribute grammar notation
which is based on the object--oriented concepts
of classification hierarchies, inheritance,
and late binding. The notation allows compact and
flexible language specification through the use of
inheritance and equation overriding. Furthermore,
demand attributes can be implemented efficiently
by using a technique similar to the one used for
virtual procedures in Simula. Such attributes are
important especially in incremental language--based
environments as they do not consume storage.
The notation also makes it possible to define
general attributes which can be accessed without
knowledge of the particular language modelled by
the grammar. This can be utilized for integration
of grammar independent tools. The notation is
based on a single--inheritance classification,
and a discussion is given on the problems which
would arise if the notation was augmented to
multiple--inheritance.",
Class = "attribute grammers, demand attributes,
language-based enviroments, single inheritance,
late binding, Simula"
)
@inproceedings(ECOOP89:Yelland,
Key = "Yelland",
Author = "Phillip M Yelland",
Title = "First Steps Towards Fully Abstract Semantics for
Object-Oriented Languages",
Pages = "347--364",
Institution = "University of Cambridge Computer Laboratory, UK",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "A number of denotational models have been
proposed for object--oriented languages. Authors
of more recent models have expressed
dissatisfaction with the lack of {"abstractness"}
in earlier ones. They claim that these earlier
models describe details of objects which are
invisible to an external observer --- in short,
that they are not {\it fully abstract}.
In this paper, we present a formal characterization
of the visible behaviour of object. We show
that using a natural full abstractness criterion
based on this definition, even more recent models
of object--oriented languages are unnecessarily
{"concrete"}. We go on to present a semantics
for a very simple object--oriented language
based on projections of state--transition graphs
for programs, and demonstrate
that it is fully abstract.",
Class = "abstract semantics, visible behavior,
state-transition graphs"
)
@inproceedings(ECOOP89:Laenens,
Key = "Laenens, Staes and Vermeir",
Author = "E. Laenens and F. Staes and D. Vermeir",
Title = "A Customizable Window-Interface To Object-Oriented
Databases",
Pages = "367--381",
Institution = "Philips PASS-AIT, KIWIS team, Eindhoven, Netherlands
and Department of Math. Computer Science,
University of Antwerp, Belgium",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "In this paper we present a user interface to the
KIWI object--oriented database system. The system
combines ease of use with a powerful customization
facility which greatly simplifies the development
of end--user applications. This is achieved by
using the underlying object--oriented language
(OOPS+) features such as inheritance to define
a consistent and orthogonal set of graphical
object classes that can be used to attach a
taylor--made external representation of (a view on)
objects and/or classes. In addition, using the
same tools, it becomes a simple matter to define
general purpose browsing and manipulation tools
which otherwise would have to be developed
separately.",
Class = "user interface, object-oriented database,
graphical objects, OOPS+, KIWI"
)
@inproceedings(ECOOP89:Coutaz,
Key = "Coutaz",
Author = "{Jo\"{e}lle} Coutaz",
Title = "Architecture Models for Interactive Software",
Pages = "383--399",
Institution = "Laboratoire de {G\'{e}nie} Informatique (IMAG),
Grenoble Cedex, France",
Month = jul,
Year = 1989,
Publisher = "Cambridge University Press",
Booktitle = ecoop89,
Organization = bcsws,
Editor = "Stephen Cook",
Abstract = "The definition of an appropriate architecture
is an important problem in user interface design.
Without an adequate architectural model, the
resulting software may be hard to modify and
maintain. Even worse, it may be unable to take
the user's characteristics into account.\\
This paper presents an overview of three
significant architectural models and proposes an
evaluation. It shows that the monolithic
sequential views of interactive software do not
match the cognitive processes involved in
computer--human interaction. Early experiences
with PAC, an object--oriented model, tend to
prove that parallel multi--agent views are
well--suited to the opportunistic behaviour
of the user and to interactive design.",
Class = "user interface design, user interface software
architecture, interactive software model,
object-oriented model, PAC"
)
-------------------------- > T U C here < ----------------------
end of ECOOP'89 bibliography.
Yours
Niels Christian Juul
DIKU (alias Dept. Comp.Sci., Univ. of Copenhagen)
Universitetsparken 1
DK 2100 Copenhagen
Denmark
Email: ncjuul@diku.dk
Phone: +45 31 39 64 66
(traillings for line-eaters)ncjuul@freja.diku.dk (Niels Christian Juul) (07/21/89)
Dear fellow-netters. I have compiled a bibliography containing the Proceedings of the Third European Conference on Object-Oriented Programming (ECOOP'89). ============================================================== The format is bibtex, but abstracts and keywords of articles are included too. The bibliography will be submittet to newsgroup comp.lang.misc in the absence of a special oop group. So look there if You want to include these references. You can also get an impression of the European OOP scene this summer, by browsing through the abstracts. % File: Bibliography/ecoop89.bib % Proceedings of ECOOP'89 European Conference on Object-Oriented Programming. % Compiled by Niels Christian Juul, DIKU, Denmark, 89.07.21. % % Though throughfull proof-readings has been done, no warrenty is given that % contents of this document is complete correct (neither should it be % complete incorrect). Yours Niels Christian Juul DIKU (alias Dept. Comp.Sci., Univ. of Copenhagen) Universitetsparken 1 DK 2100 Copenhagen Denmark Email: ncjuul@diku.dk Phone: +45 31 39 64 66 (traillings for line-eaters)