[Prev][Next][Index][Thread]

Re: Distributed objects vs. generic functions and multi-methods

----- Original Message -----
From: "Rob Myers" <robmyers@mac.com>
To: "Scott McKay" <swm@mediaone.net>; <info-dylan@ai.mit.edu>
Sent: Wednesday, October 17, 2001 8:12 AM
Subject: 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!).

When I architected a commercial high-volume web site last year, I also
eschewed these as "not ready for prime time".

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

Cool.  What's the actual book title and author?

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

It's not actually the multi-methods that are the sole problem.  It's that
in languages like Java, you have a natural "unit" for distributing around
the network -- the class.

In Lisp and Dylan, there is no such in-language unit.  So in addition to
little twists like GF/multi-methods, there's the issue of, what exactly do
you distribute?

As I said, I have not thought about this yet, and am looking for a few
shoulders to stand on.
Follow-Ups: References: