[x3d-public] JSweet translation of X3DJSAIL to JavaScript: need specific design goals first

[John Carlson]

It seems like you have issues with the “generate first” approach.   Might I
suggest this how generative and generic programming proceeds?   It seems
like you want to do a “test driven” or “test first” approach.   Might I
suggest the “automated testing” approach, combined with the “continuous
integration” approach?   That is, we generate our tests instead of writing
them.   If you didn’t notice, I am following your pattern, except I use
JavaScript and Python instead of XSLT.

It seems like you want refined examples to choose from?

That was nearly my first approach, except I was doing very short agile
sprints, thus the examples were incomplete.

Should we set aside some time for longer agile sprints?

I suggest we start pursuing the new SAI by looking at the patterns in X3D
resources examples? We should start with this to ensure backwards
compatibility.  I suggest one change.  Make the scripts run under node.js
instead of an X3D browser.

I do have some experience writing cross browser scripts.

The reason I choose the generative approach is to try to do DRY.  I would
appreciate discussing how to do DRY with both your and my framework.   I do
a lot of copy and paste in my framework and I’d like to reduce that.

If you think that procedural content is not the way to go, look at some
talks by “No Man’s Sky” authors.

I’ll include the link on another post.


On Tue, Mar 24, 2020 at 8:20 AM Don Brutzman <brutzman at nps.edu> wrote:

> John, certainly we need to pay attention to "how" a library conversion is
> performed.  JSweet is promising, and we have a number of conversion
> approached demonstrated already.
>
> But that is distracting and confusing way to solve a problem and leads to
> "fire, ready, aim!" implementation pathologies.
>
> A further risk might be that JSweet might carry through unnecessary Java
> programming idioms, but presumably they have sorted through that well
> already.
>
> First things first, please.  Let's begin with defining design goals.
> That's how we accomplished creating Java and Python programming-language
> bindings for X3D.
>
> What we really need to understand is "what" a sharable X3D JavaScript
> library looks like, and how JavaScript programmers might then use it to
> author interactive X3D models.
>
> Authoring use-case environments are
> 1. Script inside X3D scene graph,
> 2. Script in outer HTML5 web page,
> 3. Standalone programmatic use in node.js
>
> Now get specific.  Recommend listing pseudocode and design patterns for
> JavaScript Transform class and JavaScript X3D types, comparing:
>
> a. X3D ECMAScript specification,
> b. X3D Script code fields (class variables) and methods,
> c. good general-practice OO design pattern(s) in common use,
> d. current X3D JSON approach, is it OK or improvable further?
> e. compare/contrast Transform approach with X3DJSONLD,
> f. compare/contrast Transform approach with X_ITE,
> g. compare/contrast Transform approach with X3DOM,
> h. compare/contrast Transform approach with three.js,
> j. compare/contrast Transform approach with any other javascript libraries
> of interest,
> i. compatibility of Transform approach with Angular, React, jquery, other
> common JavaScript frameworks for HTML.
>
> We did this kind of comparison for X3D JSON design and it helped make a
> confusing understandable, eventually leading to good design decisions.
>
> If interested parties prepare this kind of comparison, and understand
> "what" we want that has general appeal, then progress refinement will be
> straightforward.
>
> Many people use JavaScript these days, especially with node.js - check
> whether they like the result.
>
> When you have solid patterns then we convert 4,000 X3D example scenes
> (from .x3d -> .js) to match, providing unit tests.  Lather, rinse, repeat...
>
> Hope this outline helps.  Good luck out there!  8)
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200324/f184313e/attachment.html>