[x3d-public] [x3d] Spec Comment by dougsanden on 19775-1: prototype polymorphism

Don Brutzman brutzman at nps.edu
Sun Feb 12 12:25:16 PST 2017


Doug, thanks for this interesting concept on how prototypes might be made polymorphic by having multiple candidate root nodes, selectively matching intended use.  (Also thanks for permission to share without further ado.)

Since this is a pretty sophisticated topic, am hoping you might describe further what you are thinking.

There are a number of helpful concepts regarding polymorphism on the Wikipedia page:

	https://en.wikipedia.org/wiki/Polymorphism_(computer_science)

It will be great to hear more from you on this... Beyond use cases and perhaps an pseudocode example, several issues of related interest include:

a.  New capabilities. A great variety of behaviors are already possible depending on a ProtoInstance's field (parameter) values.  Aside from language and prototype-design flexibility, is there some new capability that becomes possible through polymorphism?

b. Problem being solved.  From a scene-author's perspective, is there a particular problem or shortfall with X3D capabilities that is getting fixed by this approach?

c. Expected usage.  When do you want a single protoinstance node that can be repeatedly applied as either a Group or Shape or Appearance or Material or Texture?

d. Value of hiding (i.e. not rendering) nodes.  Perhaps an interesting design feature of a prototype is the ability to "hide" non-rendered nodes in a scene graph, for example a Script can immediately follow an initial Material node within a ProtoBody. Does polymorphism break that contract?

e. Scene graph validity.  Strict (strong) typing is a major strength of X3D scene graph; prototypes are wild cards that have strong typing checks deferred until run time.  (hmmm, perhaps X3D Validator might also check a scene for consistency).  Wondering, does polymorphism break that strong-typing contract between parent and child nodes?

f. Browser implementability.  Similar question, different POV: estimating how much more work is it for a browser builder to extend their current capabilities.

g. Design patterns.  Anything else we might learn from design and usage of other languages?




On 2/12/2017 6:42 AM, Spec Feedback wrote:
> -- Submitter indicates that this comment may be public: *Yes* --
>
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 4.4.4.3 Proto definition semantics
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#PROTOdefinitionsemantics
>
> -----------------
> Polymorphic Protos > design:
> 4. just change of spec wording and corresponding change to code behaviour in browsers:
> Current v3.3:
> "The first node type determines how instantiations of the prototype can be used in an X3D file."
> Proposed polymorphic:
> "The root node type(s) determines how instantiations of the prototype can be
> used in an X3D file: starting with the first root node, each successive root
> node is trial fitted to the protoinstance's parent node field until an
> allowed match is found. Then the match is used in the parent field to
> represent the protoinstance type."
> -----------------
>
> Submitted on Sunday, 2017,  February 12 - 6:42am
> by dougsanden (dougsanden )
>
> See: http://www.web3d.org/node/1694/submission/1230
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org


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



More information about the x3d-public mailing list