[Abora-cvs] abora-white/docs porting.html,1.12,1.13

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/abora/abora-white/docs
In directory sc8-pr-cvs1:/tmp/cvs-serv21680/docs

Modified Files:
	porting.html 
Log Message:
DGJ:
-Include Dean Tribble comments on porting

Index: porting.html
===================================================================
RCS file: /cvsroot/abora/abora-white/docs/porting.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** porting.html	23 Apr 2003 01:16:52 -0000	1.12
--- porting.html	8 Dec 2003 04:08:31 -0000	1.13
***************
*** 28,34 ****
  			the final outcome I have chosen for Abora-White.</p>

  <h3>BooleanVar</h3>

! 		This was simply replace with the Java <tt>boolean</tt>
 			primitive data type.

--- 28,38 ----
  			the final outcome I have chosen for Abora-White.</p>

+ 		<p class="feedback1 feedback-meta">Dean Tribble kindly emailed in
+ 				a few comments on the contents of this page. I have included
+ 				them below in the marked lines. Thanks Dean.</p>
+ 
  <h3>BooleanVar</h3>

! 		This was simply replaced with the Java <tt>boolean</tt>
 			primitive data type.

***************
*** 36,40 ****

  		<p>The Smalltalk native support for Integers is very powerful. For
! 			small numbers (< 29(ish) bits) a compact unboxed in-representation form
  			is used to minimise performance overhead. If an integer larger
  			than the initial range is needed then the system automatically
--- 40,44 ----

  		<p>The Smalltalk native support for Integers is very powerful. For
! 			small numbers (&lt; 29(ish) bits) a compact unboxed in-representation form
  			is used to minimise performance overhead. If an integer larger
  			than the initial range is needed then the system automatically
***************
*** 45,48 ****
--- 49,59 ----
  			other than computations start from the left.</p>

+ 		<p class="feedback1">These are intended as 32-bit integers. In the
+ 		server we were not anticipating using infinite precision
+ 				Integers.<br>
+ 
+ 				Note that the translator to X++ did manage
+ 			the transition to C++ precedence correctly.</p>
+ 
  		<p>The X++ version of Udanax-Gold seems to support just 32-bit
  			integers, which is a surprise. I guess this is either a
***************
*** 51,54 ****
--- 62,70 ----
  			IntegerVar class representations.</p>

+ 			<p class="feedback1">The 'Var' suffix meant allocated on the stack as opposed to the heap.
+ IntegerVar was defined so that we could control alignment, operators,
+ additional type checking, etc., but can be thought of as a 32 bit int.
+ 			</p>
+ 
  		<p>The Java native support for integers is split between primitive
  			data types of various bit sizes, and the BigInteger class which
***************
*** 58,61 ****
--- 74,80 ----
  			for BigIntegers.</p>

+ 			<p class="feedback1">I recommend mapping to int in Java.
+ 			</p>
+ 
  		<p>Assuming Udanax-Gold IntegerVars are required to support
  			unlimited procession, I have temporarily gone for a wrapped
***************
*** 74,77 ****
--- 93,101 ----
  			significant for the UInt32 type which is often used.</p>

+ 			<p class="feedback1">Mostly UInt32 was used for indices, for which negative numbers never
+ made sense.  They were also used for hashes.  These could almost all
+ be translated as int and it would be fine.
+ 			</p>
+ 
  		<p>The second case has to do with Strings; Java string characters
  			are unsigned 16-bit Unicode, default X++ string characters are unsigned 8-bit.</p>
***************
*** 85,88 ****
--- 109,116 ----
  			exceptions were added to the C++ specification.</p>

+ 			<p class="feedback1">I'm pretty sure they map easily to instances of type-based exceptions,
+ so the mapping to Java should be straightforward.
+ 			</p>
+ 
  	<p>Java supports a reasonable class based exception mechanism. A
  			facility beyond the Udanax-Gold exceptions is the support for
***************
*** 156,159 ****
--- 184,191 ----
  		}</pre>

+ 			<p class="feedback1">As I recall we tried to make sure that it could be translated as a
+ for-loop.  That would be a little more readable.
+ 			</p>
+ 
  		<p>...and the original Smalltalk source:<br>
  <pre>	(s _ myArray stepper) forEach: [ :e {Heaper} |
***************
*** 168,171 ****
--- 200,208 ----
  			change the return type of the super definition.</p>

+ 			<p class="feedback1">Yes.  Exposing the allocation behavior of a class when you want an
+ instance of it prevents opportunities for caching, refactoring, etc.
+ so we tried to use factory methods consistently.<br>
+ Yup, they definitely will need some renaming for Java.</p>
+ 
  		<p>I have used the Java constructors in place of the create
  			methods. This generally works out, except that Constructors have
***************
*** 175,178 ****
--- 212,219 ----
  			general factor pattern, the constructors are made protected.</p>

+ 			<p class="feedback1">Exactly the right thing.  Part of the reason for the generic naming of
+ create methods is that they were supposed to map to constructors.
+ 			</p>
+ 
  		<p>Some open issues in this area are with the area of the
  			<tt>new.Become</tt>, and possibly similar methods. Java has not
***************
*** 185,188 ****
--- 226,235 ----
  			for all objects referencing object B to now reference object A.</p>

+ 			<p class="feedback1">We did not use two-way become except to emulate behavior we could
+ accomplish in C++ some other way.  We did use one-way become for
+ converting stubs into objects during unmarshalling.  In Java, you
+ would need to use Proxies and maintain the layer of forwarding, I
+ think (or not use lazy unmarshalling).</p>
+ 
  <h3>Object Death</h3>

***************
*** 192,203 ****
--- 239,264 ----
  			the Udanax-Gold Smalltalk included these as well.</p>

+ 			<p class="feedback1">We used the post-mortem finalization support from ObjectWorks.  That's
+ where it was invented, after all :-)  For various reasons, WeakArrays
+ are much better than individual weak references, but you can still do
+ everything with individual weak references.</p>
+ 
  		<p>C++ doesn't support Garbage Collection in the default
  			implementation, and it is assumed that X++ included some kind of
  			Garbage Collection system.</p>

+ 			<p class="feedback1">Yes.  That code should be available somewhere.  It was a pretty
+ impressive GC system.</p>
+ 
  		<p>To be researched; is destruct/destroyed only relevant to X++ or
  		does it make sense for Smalltalk and Java implementation,
  			distributed and file based garbage collection support.</p>

+ 			<p class="feedback1">My recollection is that it was only for X++.  We might have used the
+ 				distinction elsewhere, but we tried not to.  One of the last things we
+ did was move the X++ GC to use post-mortem finalization (and not
+ destructors).
+ </p>
+ 
  <h3>Equality and Hashing</h3>

***************
*** 257,260 ****
--- 318,325 ----
  			creation of the Category class.</p>

+ 			<p class="feedback1">Category was part of Smalltalk.  We stuffed information there that
+ would normally be inline in a Java or C++ file (like instance variable
+ types).  In java, there should be no need for them.</p>
+ 
  		<p>For the moment the Java Class objects are being used in place
  			of Categories. In the future the Category class my need to be
***************
*** 301,305 ****
  			elements to produce different contentHashes.</li>

! 			<li>IntegerRegion:below was actually a duplicate of the above method.</li>

  		</ul>
--- 366,374 ----
  			elements to produce different contentHashes.</li>

! 			<li>IntegerRegion:below was actually a duplicate of the above
! 					method.
! 					 The scary thing is that I remember this bug, so your code may be a
! slightly-earlier-than-final snapshot.
! 					</li>

  		</ul>