[x3d-public] X3D Java SAI. Declarative style

yottzumm at gmail.com yottzumm at gmail.com
Thu Jan 19 14:17:06 PST 2017




> While I appreciate the style, I think it's harder to debug and edit 
> from a
> human point of view.   I am not compromising to make it easier for 
> the java
> compiler.

Joe wrote:
So that it is the current data structures being advanced move toward 
data storage in forms convient for the back end rather than human 
readability or functional groupings ...  more toward machine 
convenience, to me, kind of like the direction of vulcan and xflow 
definitions. This gives certain advantages of reusability, perhaps, 
but usually means that a basic human-readable form is unlikely or 
needs a highly level editing tool.

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 *consume*.  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.

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?

The more difficult your program is to write, the more difficult is it to debug.

“Debugging is twice as hard as programming”

D3.js follows along with the functional methodology and I like it.  It also allows you to define variables (read DEF and USE).

When I was originally converting XML to Java, I chose Object arrays.  Not a type safe approach.

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?).

John

Don wrote:
>> Pretty darn cool.  Some more work to follow on my part to tighten 
>> up need
>> to repeat addChildren calls for every individual child and source 
>> text, but
>> this is a big step.
>>
>> When ready I recommend you shift to declarative style to avoid need 
>> to
>> generate individual objects with unique suffixes.

Yes, we await your SAI solution.  A good, well reasoned solution, not a hack, please.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170119/cbf42917/attachment-0001.html>


More information about the x3d-public mailing list