Objective-C Issues

distributed-objects

People ( From: lines )
 burchard@horizon.math.utah.edu (Paul Burchard)
 Chris Petrilli 
 Pascal Gaudette 
 wiltel!clloyd@uunet.uu.net
Subjects ( 5 mails )
 OO Runtime, Proxy Considerations
 Re: distributed objects? (Plusses & minuses of NeXT's design)
 Re: GNU Objective-C projects
 Re: thinking ahead toward distributed objects 
 Re: thinking ahead toward distributed objects 
Document
Date: Fri, 11 Sep 92 12:20:20 -0500
From: wiltel!clloyd@uunet.uu.net
To: uunet!prep.ai.mit.edu!gnu-objc@uunet.uu.net
Subject: OO Runtime, Proxy Considerations

Hello all,

Here are a few ideas on topics which have caused problems in the past.  I think 
there may be an opportunity to affect an improvement, so here are a few suggestions.

Suggestion for runtime environment.

As I understand it, dennis_glatting@trirex.com is going to provide the runtime 
environment for the Objective-C.  As one who has developed an Object inspector 
which displays the runtime information of any object, let me strongly recommend 
that the access to the runtime environment be object oriented.  NeXT's set of
runtime functions and non-object-oriented data structures made my job much harder 
than it needed to be.  Had the runtime itself been object oriented, building an 
object inspector would have been a no-brainer.  More importantly, future 
enhancements to the runtime system would go smoother if it were object oriented.

If its too late to go object oriented with the runtime environment (for whatever 
reason), I may be able to offer a set of wrappers which makes the runtime appear 
to be object oriented;  but I would not recommend this as the ideal approach.  
Also, my code is wholly dependent on the NeXT runtime environment, so it would 
need to be adapted (not to mention completed).



Suggestion for Proxy hierarchy:

Currently, NeXT has only one class of object proxy, "NXProxy."  NXProxy is its 
own root in a new hierarchy, but it is intended for use as a Distributed Object 
proxy.  This approach is very short-sighted as there are actually many needs for 
different types of proxies (we use three different types of proxy for three very 
different purposes here at WilTel).

I propose that the gnu Object hierrarchy come with a parallel hierarchy called 
proxy_Object.  The proxy_Object class is a complete re-implementation of the 
Object class in which every method (except forward::) is renamed to 
"proxy_methodName:" where methodName: is the corresponding name in the Object 
class.  The proxy_Object class would serve as the superclass to all proxy classes 
and those application-specific proxy subclasses should add their own behavior.  
This way, the programmer can communicate directly with the proxy by using the 
"proxy_" convention and all proxies would have a common ancestor.


NOTE:  NeXT's (and WilTel's) current approach to proxies is the brute force 
approach (ie depends on forward::).  I believe the proxy concept is powerful 
enough to warrant a completly fresh approach and possible inclusion in the 
language itself.  A clever implemention of objc_msgSend() could take proxies into 
consideration and, with some minor additional syntax, programmers could 
communicate with proxies or the actual target in a much more efficient way.  If 
the language itself were aware of the proxy concept, there would be no reason to 
implement the proxy_Object hierarchy as a parallel universe.  Here's some possible 
syntax which would tell objc_msgSend() how to do its lookup:

	//Send a message to the proxy itself
	[someProxy @proxyMsg(doSomething)];

	//Send a message intended for the target of the proxy
	[someProxy doSomething];

	//Send a message to the real thing
	[someRealObject doSomething];

If done properly, this could avoid the inefficient practice of using forward::.  
Perhaps a class which conformsTo: the "Proxy" protocol would be treated as a 
proxy by objc_msgSend(), else its treated as the real thing.  The "Proxy" protocol 
might define a single method which does whatever forward:: would otherwise do.

Just some thoughts,
Charles Lloyd

Newsgroups: comp.sys.next.software,comp.sys.next.programmer
From: burchard@horizon.math.utah.edu (Paul Burchard)
Subject: Re: distributed objects? (Plusses & minuses of NeXT's design)
Date: Thu, 24 Sep 1992 01:32:42 GMT

In article <5123@rosie.NeXT.COM> sam_s@NeXT.com (Sam Streeper) writes:
> Basically distributed objects allows objects in one application to be sent  
> messages from any number other applications, as though the object were local  
to  
> those applications.  The system is pretty transparent; when you return an  
> object to a remote application, "it just works".  In fact, it's easy enough  
> that you sometimes forget you're using it.  Returning self really returns the  
> object to any application that asks!
> 
> Distributed objects makes RPC programming simple; remote messages look just  
> like local objective-c messages.

I think Distributed Objects is one of the greatest features of 3.0.  It opens  
up a whole new world of separate but "virtually integrated", interacting  
programs, which is very important to making computers really useful in  
mathematics.

However, I feel that there is one glaring flaw in the design of 3.0 D.O.'s.   
The set of message parameter types supported is just not broad enough to make  
things really transparent.  What about RtMatrix?  NXEvent pointers?  And other  
similar small but complex by-reference and union parameters?

Unfortunately, because the type encoding logic is contained in the  
communications objects rather than in the types themselves, the system does not  
lend itself to user-supplied extensions to overcome these problems.  Secondly,  
the compiler/runtime in certain cases only record promoted type descriptions  
despite explicit declarations otherwise.  For example,
	typedef float vector[3];
	- getVector:(vector)v;
Yields the type desciptor "^f" rather than the correct "^[3f]" for its first  
argument.  This makes it impossible to fix the problem with array arguments  
after the fact.

I am experimenting with my own Objective-C (socket-based) D.O. system, in which  
there is a user-extensible class hierarchy of object wrappers for C types (used  
only during communication of course).  I can do most of this on top of the  
existing run-time and compiler, but to see the full potential the compiler  
would need to generate better type descriptions, especially for array types.  

I specifically want to be able to transparently and remotely manipulate 3-D  
objects, and so RtMatrix args for Renderman calls are essential.  I'd also like  
it portable to the GNU Obj-C runtime, which is why I'm using sockets.

Anyone else thinking about this stuff?

--
--------------------------------------------------------------------
Paul Burchard	
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

Date: Tue, 13 Oct 1992 15:05:36 -0400
From: Pascal Gaudette 
To: gsk@world.std.com (Geoffrey S Knauth)
Subject: Re: GNU Objective-C projects


In comp.lang.objective-c article  you wrote:

> The GNU Objective-C project team is working on a runtime
> system, easy access to C++ from Objective-C, a class
> library, and a graphical interface builder.
>

Yes, and I think that you guys deserve a big dose of praise
for taking this on. But I have a small question:

Have you given any thought to making a GNU version of the
distributed objects system that NeXT has unveiled with
3.0? (ie NXConnection and NXProxy) This would be really
great in that it would allow developers to easily write
distributed apps in heterogeneous environments. I realize
that this would really not be an easy task, in that
a lot of the NeXT distributed objects stuff probably
relies on mach specific stuff. I would just like to know if
it has been thought of at all.

Thanks for any info,
--
Pascal "The Rascal" Gaudette       pascal@nextasy.physics.mcmaster.ca
MacNUG president                      | *NeXTmail encouraged*
graduate student, McMaster university | Je ne suis pas infaillible.
Physics and astronomy dep.            | Vive le Quebec LIBRE!

To: "Geoffrey S. Knauth" 
Cc: gnu-objc@prep.ai.mit.edu, petrilli@hal.gnu.ai.mit.edu
Subject: Re: thinking ahead toward distributed objects 
In-Reply-To: (Your message of Sat, 02 Jan 93 17:08:02 EST.)
             <199301022208.AA00895@carrara> 
Date: Sat, 02 Jan 93 20:38:07 -0600
From: Chris Petrilli 


>>>>> "KAS" == Kevin A. Sapp  writes (abridged):
KAS> I am also trying to put together a FIRST CLASS object that can be
KAS> queried (using standard objective-c syntax) about itself...how many
KAS> instance variables do you have, what is the name of the 2nd one, type
KAS> of 2nd one, ...  This would be the base class of a remote object (with
KAS> some additional methods).

Seems like a reasonable way to do this.  I am curious exactly how NeXT
has built this into NeXTstep, although I do know they have used RPC
(Remote Proceedure Call) syntax instead of Mach messages, which seems
to say to me that they are trying to be a little more portable in
theory.

KAS> I beleive these are the first steps toward distributed/remote objects.
KAS> Once one can access an objects instance variable, class, and method
KAS> information at runtime the information is there now the transfer of
KAS> this data (ala @encode strings for processor independance), method
KAS> existance, invocation and return values are some of the remaining
KAS> challanges.

Yeah, the other thing is a "standard" protocol between objects for the
communication of information.

>>>>> On Sat, 2 Jan 93 17:08:02 -0500, "Geoffrey S. Knauth"
>>>>>  said:

GAK> Kevin, you have some good ideas.  One way to see them included in GNU
GAK> Objective-C is to grab the GCC 2.3.2 sources from prep.ai.mit.edu and
GAK> add your changes to the base object.  We are accepting submissions via
GAK> gnu-objc-submissions@prep.ai.mit.edu.

GCC 2.3.3 now, but yea... and send information to the map project as
well, so that we can coordinate everything from our end.

Chris

To: Steve Naroff 
Cc: "Geoffrey S. Knauth" , gnu-objc@prep.ai.mit.edu
Subject: Re: thinking ahead toward distributed objects 
In-Reply-To: (Your message of Mon, 04 Jan 93 11:37:34 PST.)
             <9301041938.AA06651@oz.NeXT.COM> 
Date: Mon, 04 Jan 93 14:08:04 -0600
From: Chris Petrilli 


>>>>> On Mon, 4 Jan 93 11:37:34 -0800, Steve Naroff
>>>>>  said:

Steve> This is not true (in version 3.0 of NeXTSTEP)...the syntax used is  
Steve> plain old Objective-C. 

What I meant is that they were using RPC methodology underneath the
whole thing to actually accomplish the work.  I've heard from 2 people
at NeXT ... one says RPC (ie Sun ONC), and the other says Mach
messages.  I can't seem to get a straight answer from anyone.

Either way, RPC is the only real option for the GNU project since we
have to be a bit more portable.  Given that the GNU system will
eventually one day run on top of Mach, that would be nice, but I think
that RPC is a better choice for now, since the speed isn't much worse,
and the portability is MUCH better.

Steve> The Objective-C compiler and runtime work together to help
Steve> implement this functionality. The Object class publishes a
Steve> method named "forward::" to implement "proxies". The
Steve> Objective-C language implements "protocols" to help obtain type
Steve> information when the class is not local. If a protocol does not
Steve> exist, things still work, they are just a bit slower...

Minor correction: these are extensions that NeXT added to Objective-C
as far as I know, as I don't think the latest release of StepStone
will support @protocol, etc... in addition, we're STILL waiting on
access to the NeXT Objective-C front end so that we can integrate it
into later releases of GCC.  Any word on when we get access?  it's
really annoying to ME personally, not to be able to use various things
together.  I run GCC 2.3.3 for my own code (ie, non Objective-C most
of the time), but have to stick with the antiquated NeXT CC for
Objective-C... gods forbid I have to integrate Objective-C and C++ and
want an ANSI compliant C++ compiler (which NeXT does not ship).

Chris
Statistics
 filename:           distributed-objects
 number of mails:    5
 number of writers:  4
 line count:         253
 word count:         1838
 character count:    12096

created by Helge Hess ( helge@mdlink.de )
MDlink online service center ( www.mdlink.de )