From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Newsgroups: comp.lang.ada
Subject: Re: Handling objects in a distributed system
Summary: Incorrect assumptions, ... there are alternatives
Message-ID: <558@ajpo.sei.cmu.edu>
Date: 23 Aug 89 17:44:25 GMT
References: <58310@tut.cis.ohio-state.edu>
Distribution: usa
List-Id: <comp.lang.ada>

In article <58310@tut.cis.ohio-state.edu>,
murali@catamaran.cis.ohio-state.edu (S Muralidharan) writes:

> 
> Vladmir G. Ivanovic writes:
> 
> >Maybe there is something I'm missing, but why on earth would one want
> >to send an object to another node?  Isn't it like passing an array to
> >a procedure?  Why not just pass the name of the object?  In a truly
> >distributed system, the name server will provide the access path.
> >Then there is only one copy and no consistency problem.
> 
> 	A very good question. In fact, in the context of reusable software
> there are several problems with any object movement. 

I agree. These problems will impact both class and system design.

> 	Any approach which advocates object movement generally assumes
> that a single person is both the developer and a client of a
> component.

As Murali says later, this is indeed an invalid assumption. I am not
sure, however, whether anybody actually makes this assumption. If
someone is unfamiliar with object-oriented technologies, specifically
with the issues of object, class and system design, they might make
this mistake.

> This assumption is certainly invalid, if software reuse
> is based on component specifications and not source code, 
> as done in Ada. While only the developers know the details of the software, 
> only the clients know the nature of the hardware architecture where 
> the software would be executed.

I agree.

As I said in a previous posting, depending on the situation, "object
[and class] movement" may be a necessity. Please note, that I am not
advocating that objects and/or classes be moved without some technical
justification. Nor am I saying that "object movement" will be the
norm. I am merely suggesting it be an option which is selected based
on some sound technical judgement.

				-- Ed Berard
				   (301) 353-9652