[2624] in java-interest

home help back first fref pref prev next nref lref last post

Re: typesafe socket communcation (resending)

daemon@ATHENA.MIT.EDU (Gary Aitken)
Sat Oct 7 04:27:12 1995

Date: Fri, 6 Oct 1995 23:09:32 -0600
From: garya@village.org (Gary Aitken)
To: Jim Greer <jgreer@eden.com>
Cc: java-interest@java.sun.com

>Now, non-atomic data members clearly pose a major problem.  If there is 
>some data element like an array or another object inside of this class, 
>then the typecast is much more compilcated.  Here are two potential ways 
>to deal with this that would solve our problems:
>
>1. Disallow runtime casts (i.e. generate an exception) for casts to 
>classes which contain non-atomic members.  Disadvantage: no arrays! :(

This seems like the least of your worries.  Virtually every complex
OO system I have ever seen ends up with lots of ptrs to other objects
as members of any given object.  e.g., in a linked list each element
contains ptrs to the prev and next ele.  You can't linearize this type
of info as you did with the byte array because the objects referenced
may be (and often are) shared, in the sense that several different objects
may point to any particular one of the out-of-line references.

You can, however, resolve these sorts of things using named references
and dereferencing the names as the data stream is read in, much the way
a conventional loader backfills forward references.

Gary Aitken		garya@village.org
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post