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

Quote:

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

Not every language feature solves every problem equally well.

Multiple dispatch offers many advantages over traditional "message
passing" dispatch.  But those advantages may not apply in all
application domains.

In distributed programming, objects may be on different machines.  And
although the "recipient agnosticism" of multiple dispatch is usually a
huge win, it's doesn't give you any idea which server should run the
code.

So this looks like a small, localized loss to me, and not even a serious
one.

Quote:
> I'm sure there are people who have thought about this.  I would
> be very interested in what ideas you might have.

I think you're suffering undue agony. :-)  Just slap together a "define
interface" macro, assume that the first argument to a remote function is
the target, and sleep easily.

Both macros and multiple dispatch are well-solved problems, and they
offer tremendous wins in lots of real-world designs.  The fact that
weaker forms of dispatch are well-suited to certain programming idioms
shouldn't come as any suprise.

I /do/ think that there should be some way to declare the dispatching
and non-dispatching arguments of a generic function, however.

Cheers,
Eric
(who'd rather have the power and not need it, than vice versa)



Sun, 04 Apr 2004 03:43:26 GMT  
 Distributed objects vs. generic functions and multi-methods

Quote:

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

Quote:

>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



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


Quote:

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

> Not every language feature solves every problem equally well.

> Multiple dispatch offers many advantages over traditional "message
> passing" dispatch.  But those advantages may not apply in all
> application domains.

> In distributed programming, objects may be on different machines.  And
> although the "recipient agnosticism" of multiple dispatch is usually a
> huge win, it's doesn't give you any idea which server should run the
> code.

> So this looks like a small, localized loss to me, and not even a serious
> one.

> > I'm sure there are people who have thought about this.  I would
> > be very interested in what ideas you might have.

> I think you're suffering undue agony. :-)  Just slap together a "define
> interface" macro, assume that the first argument to a remote function is
> the target, and sleep easily.

I've got a 'define interface' macro, but what is lacking in Dylan
is enough MOP to enforce the protocol you defined.

- Show quoted text -

Quote:
> Both macros and multiple dispatch are well-solved problems, and they
> offer tremendous wins in lots of real-world designs.  The fact that
> weaker forms of dispatch are well-suited to certain programming idioms
> shouldn't come as any suprise.

> I /do/ think that there should be some way to declare the dispatching
> and non-dispatching arguments of a generic function, however.

> Cheers,
> Eric
> (who'd rather have the power and not need it, than vice versa)



Sun, 04 Apr 2004 08:23:20 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:
> 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.

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

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



Sun, 04 Apr 2004 20:17:56 GMT  
 Distributed objects vs. generic functions and multi-methods

Quote:
----- Original Message -----


Sent: Wednesday, October 17, 2001 8:12 AM
Subject: Re: Distributed objects vs. generic functions and multi-methods


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

Quote:
> 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?

- Show quoted text -

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



Sun, 04 Apr 2004 20:31:37 GMT  
 Distributed objects vs. generic functions and multi-methods

Quote:
> What's the actual book title and author?

"JavaSpaces(tm): Principles, Patterns and Practices"
Eric Freeman et al

http://www.amazon.com/exec/obidos/ASIN/0201309556/qid=1003322112/sr=8...
sr_8_3_2/102-3322930-8268135

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

Well, Lisp Conses could be distributed: the head and the tail would be
either local objects or remote objects, "NetConses". This may be a little
fine-grained, though. :-)

Quote:
> So in addition to
> little twists like GF/multi-methods, there's the issue of, what exactly do
> you distribute?

I see. Java's ability to send bytecodes 'down the wire' hides the fact that
functionality is distributed and stays there for the duration of processing
whether it's installed by hand or fetched from a server, but data is
processed and returned. Unless self-modifying Lisp code is the data being
distributed.

I do think that for Dylan that if you don't use spaces you end up
concentrating on data objects for distribution, using the Objective-C proxy
& call object model.

- Rob.



Sun, 04 Apr 2004 20:50:36 GMT  
 Distributed objects vs. generic functions and multi-methods

Quote:

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

CORBA's Objects-by-Value also assumes the implementation is available locally
for languages that aren't Java.

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

I think the question is: But to which server do you send the gf call, Dear
Liza, Dear Liza?

FTR, the Fun'Dev CORBA implementation sends the operation call to the server
associated with the first object reference, as you might expect.

__Jason



Sun, 04 Apr 2004 21:50:47 GMT  
 Distributed objects vs. generic functions and multi-methods


Quote:
> I think the question is: But to which server do you send the gf call, Dear
> Liza, Dear Liza?

You send the GF call to the GF: the GF is an object, so whichever machine
the GF object resides on receives the call. Think of every GF call as a call
to a single magical 'dispatch' method with the GF object always as the first
parameter. The local 'GF' may contain a proxy method that sends the method
call to the server, or it may just be a normal local method.
Eventually one of the methods will call a method on another machine. This
method may well be a slot accessor. Using the Proxy system, slot accessors
on proxy objects are virtual slots that send the value request to the
machine the object actually resides on.

There was an interesting series of articles on JavaWorld about a form of
object design where you (theoretically) never used accessors. Objects were
defined by behaviour (callable methods) rather than properties (data). This
might be an interesting model for a distributed system using GFs.

http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

- Rob.



Sun, 04 Apr 2004 22:08:24 GMT  
 Distributed objects vs. generic functions and multi-methods

Quote:

> ----- Original Message -----

> Sent: Wednesday, October 17, 2001 8:12 AM


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

This may not be the answer to quite the right question but, in terms of
code "migration": libraries (compiled with "loose cross-library linking")?

Kaelin Colclasure earlier mentioned the problem of incremental updates to
code on different nodes.  Dunno if it's of any interest but a friend of
mine did his PhD on a so-called "Dynamic ML" which addresses run-time
dynamic updates to ML modules on other machines (with ML's usual formal
correctness guarantees).  Not actually implemented yet, AFAIK, but it has
a chapter on how the formal side might be applied to Java.  See
<http://www.dcs.ed.ac.uk/home/cdw/>, though I couldn't find the thesis
online.

Just my (friend's) 2p :-)

Hugh

--
Version 3.1 GCS/IT d- s+:+>+: a- C++$ UL P+ L+(++) E W++$ N++ o K++ w(++) O?
M V? PS(+) PE Y+ PGP->++ t(+) 5+(++) X(+) R tv b++ DI+ D+ G e++ h- r>++ y+
(Removed reversed spam from my email address to reply)



Mon, 05 Apr 2004 05:45:44 GMT  
 Distributed objects vs. generic functions and multi-methods
Hugh Greene wrote

Quote:
>Kaelin Colclasure earlier mentioned the problem of incremental updates to
>code on different nodes.  Dunno if it's of any interest but a friend of
>mine did his PhD on a so-called "Dynamic ML" which addresses run-time
>dynamic updates to ML modules on other machines (with ML's usual formal
>correctness guarantees).  Not actually implemented yet, AFAIK, but it has
>a chapter on how the formal side might be applied to Java.  See
><http://www.dcs.ed.ac.uk/home/cdw/>, though I couldn't find the thesis
>online.

>Just my (friend's) 2p :-)

Ah, interesting. I'll have a look sometime.

Also, anyone seriously interested in distributed systems owes themselves
a look at Erlang -- a functional language specifically tailored to the
domain. There is even an open source implementation to play with.

<http://www.erlang.org/>

-- Kaelin



Mon, 05 Apr 2004 06:58:19 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  
 
 [ 13 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