Distributed objects vs. generic functions and multi-methods 
Author Message
 Distributed objects vs. generic functions and multi-methods

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.



Sat, 03 Apr 2004 22:34:39 GMT  
 Distributed objects vs. generic functions and multi-methods

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



Sat, 03 Apr 2004 23:54:02 GMT  
 Distributed objects vs. generic functions and multi-methods

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



Sun, 04 Apr 2004 16:16:45 GMT  
 Distributed objects vs. generic functions and multi-methods

Quote:

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



Tue, 06 Apr 2004 21:46:09 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Distributed objects vs. generic functions and multi-methods

2. Generic Functions vs. CLOS Methods

3. Advantages of function objects vs. classes/methods

4. string object methods vs string module functions

5. Anybody working on generic functions w/ multimethods, too?

6. ENSURE-GENERIC-FUNCTION and method combinations?

7. Inspecting the methods associated to a generic function

8. Are all functions multi-methods?

9. Multi-methods (was Re: Overloading function calls)

10. message passing vs. generic functions

11. generic interface real function vs real

12. Multi-methods, multi-polymorphism in python

 

 
Powered by phpBB® Forum Software