<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> While I appreciate the style, I think it's harder to debug and edit </p><p class=MsoNormal>> from a</p><p class=MsoNormal>> human point of view. I am not compromising to make it easier for </p><p class=MsoNormal>> the java</p><p class=MsoNormal>> compiler.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Joe wrote:</p><p class=MsoNormal>So that it is the current data structures being advanced move toward </p><p class=MsoNormal>data storage in forms convient for the back end rather than human </p><p class=MsoNormal>readability or functional groupings ... more toward machine </p><p class=MsoNormal>convenience, to me, kind of like the direction of vulcan and xflow </p><p class=MsoNormal>definitions. This gives certain advantages of reusability, perhaps, </p><p class=MsoNormal>but usually means that a basic human-readable form is unlikely or </p><p class=MsoNormal>needs a highly level editing tool.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I do not see the new Java SAI document “encoding” as being standardized or something that a high level editing tool or back end will *<b>consume</b>*. And that is important here. We could build something that would take ANY Java and produces a scene graph, simply by printing out the X3D object at the end. The point here is that both techniques generate a scene graph. I view the PRIMARY purpose in developing a style to 1) test the SAI 2) provide an example for developers. I think a cross between the two styles is the best approach—like defining variables for each node and not reusing the variable for setting attributes, but perhaps generated Java is not good at expressing a cross (know a language that does? Scala?)? Something like JSON or XML would be better. I think Don is merely highlighting that the Declarative/Functional approach is better, and I don’t disagree with him. However, I think it may be problematic achieving his goals, and to do purely may require some getParent() routines to do right, which we should consider whether we should add a parent reference to many objects or not. Otherwise, we are still storing variables. (I think the getParent() may also break down the gains earned by parallelism, but don’t quote me on it). That is, we can either store the variables inside the objects or outside the objects. Data hiding leads us to want to store them inside the object, I just don’t like the security implications of a child (subclasses) being able to access the parent environment.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If I am testing the SAI, I should test it in all ways that humans will use it. Don first proposed one method, which I followed along with. Then Don proposed another method, which I haven’t signed off on, at least until he solves the addChildren/getParent issue. We do need a way to debug the SAI, and if my technique is hindering us from debugging or developing the SAI, that should be made better known. Right now, I am just at the point where I’m starting to compare inputs with outputs (well, a little beyond it). I would rather continue with what I have, believing that programmers will write code that will be easily debugged, than write some functional stuff that requires a Lisp PhD to debug—or clicking down a whole hierarchy of objects. Yes, I understand that functional programming is the hot thing to do now. I don’t think people should get PhDs in order to debug my code. Yes, I realize some environments make it extremely easy to debug large functional objects. Can we document which ones?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The more difficult your program is to write, the more difficult is it to debug.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>“Debugging is twice as hard as programming”</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>D3.js follows along with the functional methodology and I like it. It also allows you to define variables (read DEF and USE).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>When I was originally converting XML to Java, I chose Object arrays. Not a type safe approach.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Also any Java code in a single chunk is going to run into the method size constraint. We should pick the best method which allows us to break the code up into separate methods (and how will we name those methods?).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Don wrote:</p><p class=MsoNormal>>> Pretty darn cool. Some more work to follow on my part to tighten </p><p class=MsoNormal>>> up need</p><p class=MsoNormal>>> to repeat addChildren calls for every individual child and source </p><p class=MsoNormal>>> text, but</p><p class=MsoNormal>>> this is a big step.</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> When ready I recommend you shift to declarative style to avoid need </p><p class=MsoNormal>>> to</p><p class=MsoNormal>>> generate individual objects with unique suffixes.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Yes, we await your SAI solution. A good, well reasoned solution, not a hack, please.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p></div></body></html>