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

[John Carlson]

My iPhone isn’t pasting.  I suggest looking for the talk about the game by
searching for the game plus GDC or noise.

On Tue, Mar 24, 2020 at 5:48 PM John Carlson <yottzumm at gmail.com> wrote:

> 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/b10c1a99/attachment-0001.html>