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

[Andreas Plesch]

In terms of Ecmascript best practices this widely followed style guide
has many, rather strict rules to follow:

https://github.com/airbnb/javascript/blob/master/README.md

On Wed, Mar 25, 2020 at 9:46 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Hi John, Don,
>
> I am trying to follow the discussion somewhat but have quite limited
> availability now.
>
> Here are some considerations, unfortunately quite unconnected.
>
> Ecmascript best practices
>
> It is not clear that there are commonly accepted standards since the
> language is forgiving having evolved so much. But here are perhaps
> some guides. An often encountered viewpoint is that the language is
> not very OO oriented but rather functional in nature. So OO principles
> do not necessarily apply but could be used anyways. There are now
> classes in Ecmascript although my understanding is that they are
> largely considered syntactical sugar. Another principle is that since
> it is a largely interpreted language which relies on garbage
> collection, object reuse is favored over object creation and
> destruction. Three.js, for example, is very strict about this, and
> part of the reason why it is performing well. x3dom is not very strict
> about this on the other hand, and still does ok. As node.js is a
> target one needs to be careful to distinguish between DOM/browser
> features and language features. Node.js natively does not have DOM
> methods but a DOM and methods can be added with a library. Also, keep
> in mind that currently there is no X3D runtime for node.js.
> x3dom/x_ite cannot be run in node.js. So one, expensive, experiment
> would be to try to extract a node compatible runtime by separating the
> rendering and input controls out of these engines.
>
> Scene Authoring/Construction versus Scene Access
>
> Ecmascript differs from Python or Java in that it is the primary
> language for X3D scripts used internally in scenes, and externally to
> access scenes in running browsers. This is what the current SAI spec.
> defines, and what I understand to be Scene Access. This includes but
> is not limited to constructing new nodes and entire scenes
> programmatically. In addition to construction, SAI also allows for
> controling a browser, and modifying a running scene. In contrast,
> X3DJ/PSAIL is limited to constructing and authoring a scene which can
> eventually be serialized as xml or json, and be used to load into X3D
> browser. It seems perhaps prudent for now to parallel X3DJSAIL and
> just focus on scene authoring, and not be concerned about live scene
> control and modification.
>
> JSON
>
> Since the X3D JSON encoding now exists, a useful and specific question
> is if the Ecmascript JSON.parse() function
> (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse)
> should return a value which can be immediately used by the envisioned
> library given a JSON encoded string. Conversely, should the Ecmascript
> JSON.stringify() function generate directly X3D JSON encoding if given
> a library generated object ?
>
> -Andreas
>
>
>
> On Tue, Mar 24, 2020 at 9: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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453