[x3d-public] Builder pattern for next gen X3DJSAIL [ NOT IMPORTANT ]

[John Carlson]

The main idea is to write X3DLoaderJava, X3DLoaderJSON, X3DLoaderVRML, 
X3DLoaderJavaScript, X3DLoaderPython, ... , toFileJava, toFileJSON, ... 
etc. for APIs, API examples, Schemas, Encoded Documents, Object Models, 
etc. etc.  In a very object-oriented fashion.  If we ultimately do this 
with XSLT or Java, I don't care, but we should define good interfaces to 
support immutability and encapsulation.

Suggestion:  Revisit Cameron Browne's "class grammar" for maintaining 
and enhancing code.  I think we should consider maintaining source code 
in revision control, or maintaining versions of jars which contain 
source code.

I have not heard of  a Java Code Builder like there is a Dart code builder.

John

On 8/1/21 12:26 AM, John Carlson wrote:
>
> https://howtodoinjava.com/design-patterns/creational/builder-pattern-in-java/
>
> Builder in Dart:
>
> https://github.com/dart-lang/code_builder
>
>
> I call the Builder pattern the Importer/Exporter pattern.  One passes 
> the Importer or subclass to the node or statement constructor, and the 
> Exporter, Formatter or subclass is passed to the node or statement 
> outputter.  I think it would be a good plan to pass a Builder or 
> Importer to a constructor in Java.
>
> Main advantages:   1) Immutability  2) Encapsulation
>
> Main disadvantages:  1) code bloat.
>
> According to the first link, you create a Builder as an enclosed class 
> of the class you want to build. You can have a class hierarchy of 
> Importer/Exporters you want for different encodings, etc.
>
> Obviously, I offer this as an alternative to XSLT hell. However, we 
> may need to bootstrap with XSLT, I think, and it would be good to have 
> roundtrip with the XSLT. My preference is to bootstrap into Java. Then 
> add different Exporters as alternatives to the XSLT Exporter.  For 
> exporting, you pass the exporter to the outputter method, and then 
> extract any data values using getters on the exporter.
>
> Obviously this is a step away from the "Java Beans," "Enterprise Java 
> Beans," "Plain Old Java Object" and "Data Transfer Object" patterns of 
> Java.  The important thing is immutability and encapsulation for 
> proper object-oriented design.
>
> I think this would be a good pattern for Blender I/O plugins to 
> follow. Would it be possible to generate the Blender X3D plugins from 
> X3DJSAIL?
>
> What I will attempt to do is create a new Serializer in JavaScript to 
> produce Java "Importer/Exporter" examples, but I may need to dig into 
> X3DJSAIL.  Perhaps I can treat current X3DJSAIL classes as 
> importer/exporters. I think this way, we can advance step-by-step to 
> the next generation of X3DJSAIL.
>
> Question:  Does C/C++/C# SAI or other SAI already follow this? Is this 
> "CreateX3dFromString()"?
>
> John
>
> Additionally, I will work with es6x3d and x3d.dart to adopt 
> importer/exporter patterns.
>
> I do not see this as a problem per se for Python or Dart.  But it 
> would be good to have exporters for Python and Dart in X3DJSAIL.  It 
> may help with the pyjnius X3DJSAIL-Python SAI.
>
> I am thinking of leaving the org.x3d.web3d.jsail as 
> Importers/Exporters and starting a new package next to sai and jsail 
> in X3DJSAIL.  Perhaps there would be some organization of 
> Importers/Exporters by input/output language under jsail.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210801/6e9afc8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghbdliffapgbeehp.png
Type: image/png
Size: 238130 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210801/6e9afc8e/attachment-0001.png>