You need to be very careful with this kind of thinking.  A remote object is
VERY different from a local object.  You can make very different guarantees
about a local object.  When communicating with a remote object you need to
deal with communications delays, failures and so on.  What happens when your
method send works but the result message does not make it back?  What
happens when the delay to the remote object is 1/10th of a second?  Or 1
second?  The idea that remote communications can be transparent is what has
killed almost every distributed computing effort to date.  The one thing
that the web services people got right is that you need to know when you are
talking to a remote object and handle that differently than those in memory.
Any other approach produces toys or failures.

That said, a dynamic language like Smalltalk or Ruby makes this much easier
to do well.  You can have a proxy for a remote object that also has added
behavior that allows you to deal with the communications issues, or add
transactionality to the interaction, etc.

I think there is an opportunity to define a new languge that has
transactional semantics in memory as a way to deal with both remote
communications and concurrency.  But, transparency is not useful.  As in
your example you would not want to have a superclass on another machine and
have that result in communications to the other machine every time you check
for implementors of a method for a method send.  Being able to reference a
class from another addres space and have it migrate or clone into your
address space might be useful and having language support for manipulating
and accessing objects/classes in multiple address spaces might be
interesting as well.

Michael



> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Martin Drautzburg
> Sent: Saturday, October 07, 2006 12:41 PM
> To: The general-purpose Squeak developers list
> Subject: Everything is a distributed object
> 
> Hello all,
> 
> I've seen various attempts to add distributed computing capabilities on
> top of
> an existing language. For a true distributed system I would expect it to
> be
> possible to instantiate objects of a remote class or to subclass a remote
> class and other stuff like this. My impression is that those things are
> difficult when built on top of an existing language.
> 
> Since the paradigm "everything is an object" pays so well, I thought it
> might
> be less painful to implement a distributed system from ground up, starting
> with the paradigm: "everything is a distributed object". Maybe languages
> like
> Erlang and E get close to this paradigm. Other than those I am not aware
> of
> any attempts to implement distributed computhing in this way (from ground
> up).
> 
> Are you aware of any ?
> 
> As a sidenote: I have difficulties to understand how Smalltalk works,
> especially the way method calls eventually resolve to primitive calls. I'd
> be
> most grateful for an explanation the other way round, i.e. starting with
> the
> primitives and the way the entire system builds up from them.
> 
>