[x3d-public] Check parameters for range, enum, what else? TypeScript?

[Joseph D Williams]

➢ Also note that ProtoInstance is acceptable anywhere a node is acceptable, further type checking (i.e. is that an acceptable ProtoInstance?) has to occur in the library - usually the setter is a good place for that.

Important is that we are able to check types at authortime. With xml schema it is possible to do that for spec nodes using the spec schema. For prototype definitions it id desired that the xml authortime tool augment the spec schema by perhaps generating an equivalent prototpe instance schema for each prototype; for reuse validating the instance? 

It is not unusual to use several different prototypes and several instances of the same prototype. Anyway, It is nice to be able to troubleshoot some prototype instance placement in the hierarchy and simple checks for appropriate field values without having to run the things. Of course a dedicated author might do this manually, but it would also be handy to have this as some level of convenience for some level of authoring system.

 I think this might also be a solution to the rather,  as I read it,  clumsy legacy appearing user code now required for xml prototype instances. If we have a schema instance for the proto instance, then we have complete authortime validation, at least. And, instance can then look like a usual node in the user code courtesy of the augmented schema. 
Maybe a deep reason that html doesn’t know about structures like prototypes. Can’t allow a ‘live’ schema!

Thanks, 
Joe



From: Don Brutzman
Sent: Tuesday, June 16, 2020 6:37 PM
To: John Carlson
Cc: X3D Graphics public mailing list; Peitso, Loren (CIV)
Subject: Re: [x3d-public] Check parameters for range, enum,what else? TypeScript?

Yes stick with primary types first.  Then do Field types: SFFloat, SFVec3f, etc.  Then look at overloading with convenience methods/constructors, each programming language varies in that respect.

On 6/15/2020 8:14 PM, John Carlson wrote:
> I am checking parameters for range, enum, length, not type(s) yet, ... what else is there for setter and constructor parameter checking?
> 
> My first gulp would be to give parameters to their types, ala TypeScript.  That would be one way to solve the parameter type problem. Is it OK to convert my ES6 x3d.mjs module to TypeScript? Those who are against the coffee languages might approve.
> 
> I can see that the X3DUOM supports multiple types for parameters.

for most fields it actually is no, X3DUOM only gives a single primary type for basic (non-node) types.

For content model, sometimes it is a mix of node types and nodes that are acceptable in an SFNode/MFNode field  Also note that ProtoInstance is acceptable anywhere a node is acceptable, further type checking (i.e. is that an acceptable ProtoInstance?) has to occur in the library - usually the setter is a good place for that.

Looking at X3DJSAIL Java (Javadoc or source) and x3d.py will give examples for each and every case that you can use as exemplars to check your patterns.  They will likely be the same, just expressed a bit differently in each language.

> It looks like TypeScript allows overloading as well.
> 
> Thanks,
> 
> John

Doing TypeScript as a more rigorous/debuggable path to get towards EcmaScript certainly sounds appealing, as Cecile describes.

Hope you aren't feeling faint of heart - but it does aggregate nicely as you produce autogeneration patterns.

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

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200618/4741fa8e/attachment-0001.html>