[Prev][Next][Index][Thread]
Re: Distributed objects vs. generic functions and multi-methods
Scott McKay wrote:
>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.
>
It is true enough that the mapping from a message-oriented
(single-argument dispatch) object system to a remote process interaction
protocol is straightforward. I will even grant that the idea of using a
``class'' as the first-class representation of such a protocol has its
appeal. However, my ideal ``distributed object system'' would give
priority first to providing a level of expressiveness sufficient to
designing workable and maintainable remote process interaction
protocols, and only secondarily to conveniently mapping said protocols
onto existing language constructs. I believe that Java and CORBA both
have these priorities reversed.
For example, neither system adequately addresses the requirement of
providing for incremental evolution of individual components of the
distributed application.
>
>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.
>
Lisp and Dylan both provide macro systems more than adequate to the task
of providing a formal framework for protocol definitions -- ultimately
represented as a class, if that makes sense in the architecture overall.
Moreover, features such as keyword arguments (with default values) and
multiple return values provide expressive support for requirements
common to remote process interaction protocols that e.g. Java sorely
lacks (and that therefore Java's distributed object system does not
expressly support).
The only aspect of Java that really appeals to me vis-a-vis distributed
systems is the ability to send code over the wire, and the
infrastructure to receive and execute it without compromising the
integrity of the application. And even here, I think Lisp offers a
superior semantic model.
-- Kaelin
References: