[Prev][Next][Index][Thread]
Re: Distributed objects vs. generic functions and multi-methods
on 16/10/01 3:45 pm, Scott McKay at swm@mediaone.net wrote:
> I've been reading a book ("Enterprise Java Beans", by Richard
> Monson-Haefel) which describes the EJB distributed object
> architecture.
Java's recognition that distributed methods may fail for network-related
reasons is good. Explicitly having a method indicate that the network died,
or that lag is too great to get a real-time answer, is better than just
failing. JavaBeans and EJBs are a bit clunky, though. We avoided the
technology when I was an enterprise Java programmer (2 years ago now!).
The JavaSpaces book is the last programming book I read that really made me
go "wow!". Imagine a Dylan version with data objects placed into and taken
out of the space as XML (or another object representation) and processed by
code on local machines. A GF call becomes a pattern for storing objects in
the space, (de)serialized & dispatched by the local runtime.
Or even an 'open' version with XML and JavaScript as the object/code
representation. I think I've mentioned this idea before. :-)
NeXT's distributed Objective-C runtime is interesting, too. Objects to
represent messages sent to proxies can be done in Dylan: GF calls as objects
sent to a remote runtime. Proxies become objects with virtual slots that
call remote methods, and/or 'tag' objects that make the GF dispatch to a
method that calls a remote method. This would be my preferred way of doing
distributed Dylan: I think it fits very well.
> 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.
Java is an interesting case because the (bytecoded) code can be transmitted
as objects. Lisps can do this with interpreted code, but current Dylan can't
transmit code across a heterogenous network.
Next's distributed Obj-C requires that you have the code already on each
machine, so Dylan doesn't really lose out by requiring "manual" distribution
of code, and its separation of methods from classes actually makes pure data
objects a natural choice of entity to send over the network.
> 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".
OK, I'm ignorant here. :-) Why would multi-methods get lost in a distributed
system? Why do we need a "protocol"?
- Rob.
Follow-Ups:
References: