I'm a long-time detractor of purely class-based modularity,
preferring the generic functions / multi-methods plus a package
(or module) system to control access. I have just run upon
some things which are making me do a little reflection...
I've been reading a book ("Enterprise Java Beans", by Richard
Monson-Haefel) which describes the EJB distributed object
architecture. For the most part, this looks like a pretty good
architecture for doing this sort of thing, though from a client
programmer's point of view, using it is probably kind of a pain
due to Java's lack of good code re-use (multiple inheritance).
What has piqued my curiosity is, what does a good distributed
object system look like in a language in which generic functions
with multi-methods are the things around which designs are
composed? In a class-based decomposition, there are natural
things which can be "distributed" -- the [instances of the] classes.
In Lisp or Dylan, it's not obvious to me what to "distribute"...
It's not enough to say "oh, just lose the multi-method part and
only dispatch on the first argument", because these languages
still don't provide a formal way of grouping all the related GFs
into a single first-class "protocol".
I'm sure there are people who have thought about this. I would
be very interested in what ideas you might have.
From: Marco Antoniotti
Subject: Re: Distributed objects vs. generic functions and multi-methods
Date:
Message-ID: <y6cu1wzk2cl.fsf@octagon.mrl.nyu.edu>
I had a (heated) discussion a very long time ago (circa 1994) about
this very same topic.
My answer was: you distribute the generic functions. Which in todays
parlance would be: you write servers (somewhat special objects) which
implement a given interface. I guess this is the best you can do.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Vebjorn Ljosa
Subject: Re: Distributed objects vs. generic functions and multi-methods
Date:
Message-ID: <cy3elo2y93m.fsf@ljosa.com>
* "Scott McKay" <ยทยทยท@mediaone.net>
|
| What has piqued my curiosity is, what does a good distributed
| object system look like in a language in which generic functions
| with multi-methods are the things around which designs are
| composed? In a class-based decomposition, there are natural
| things which can be "distributed" -- the [instances of the] classes.
| In Lisp or Dylan, it's not obvious to me what to "distribute"...
In principle, I think it's fine to distribute the object
instances---i.e, the slot values---without requiring the methods to be
executed on the node where the data are stored. The method itself can
run on any node, of course making lower-level calls corresponding to
slot-value and (setf slot-value) whenever a slot value is referenced.
But this opens up a whole can of worms. For a start, methods and
subclass definitions will have to be propagated between nodes in a
consistent manner. And because the methods can refer to symbols, they
would have to be distributed as well. You would end up with a truly
distributed Lisp instead of individual Lisps communicating through a
middleware. Could be interesting, but I'm not yet convinced that it
is a a good thing.
--
Vebjorn Ljosa
From: Steven M. Haflich
Subject: Re: Distributed objects vs. generic functions and multi-methods
Date:
Message-ID: <3BD02EA1.CEA53685@pacbell.net>
Vebjorn Ljosa wrote:
> But this opens up a whole can of worms. For a start, methods and
> subclass definitions will have to be propagated between nodes in a
> consistent manner. And because the methods can refer to symbols, they
> would have to be distributed as well. You would end up with a truly
> distributed Lisp instead of individual Lisps communicating through a
> middleware. Could be interesting, but I'm not yet convinced that it
> is a a good thing.
This is essentially one way a persistent object database can be
designed to work. I speak from my experience with Franz AllegroStore,
which is built on top of Excelon's ObjectStore. Multiple client
programs can `simultaneously' access each database, and that database
holds both instances and their class definitions. The first time a
an instance of a persistent class is referenced within each
transaction, the in-heap copy is compared for currency with the in-db
copy, and the differences reconciled with something akin to the usual
CLOS class updating protocol. The client application can control
whether to give precedence to the definition in the db (in order to
learn about updated definitions) or to the definition in the heap
(in order to propagate local changes to the database, and then
presumably to other distributed clients). The clients don't need to
be homogenious, i.e., they different OS and processor architecture
implementations can share a common database.
So ObjectStore more-or-less incidentally provides an environment
automatically suited to distributed applications, just as does almost
any multi-client database. All this incurs some overhead (and cost)
of course, and the real purpose of a persistent object database is to
provide a persistent object database, so one should indeed consider
the other alternatives for distribution if the persistent object
database component is not a useful part of the picture.