[x3d-public] ProtoBody completeness in nested Protos

Wed Apr 27 21:23:17 PDT 2022

Thanks for your precision and thoroughness Doug.

Seems clear and unambiguous that it is scoped, as previously described.
We'll double check on phraseology.

Dick can we please discuss in tomorrow's meeting, TIA.

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 https://
faculty.nps.edu/brutzman

From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of GPU Group
Sent: Tuesday, April 26, 2022 9:57 AM
To: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] ProtoBody completeness in nested Protos

https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.
html#Prototypescopingrules

"A prototype may be instantiated in a file anywhere after the completion of
the prototype definition."

If the specs meant what you are suggesting --protos are self contained
including proto definitions-- then it would have said "context" rather than
"file"

"Prototype definitions appearing inside a prototype definition ( i.e.,
nested) are local to the enclosing prototype. "

- refinement of the above file order rule.

On Tue, Apr 26, 2022 at 9:51 AM GPU Group <gpugroup at gmail.com
<mailto:gpugroup at gmail.com> > wrote:

"I really do
not think that proto declarations should be required to inherit
existing declarations from parent execution contexts"

If C++ required each class definition to be self-contained --to redefine all
the types it depends on-- it would be a very messy and onerous system. If
you want a system that can build up types - types on top of types to make
more complex types - then you need a way for a type to use previously
defined types.

In x3d -a prototyping language- that looks like a new type being able to use
a type defined previously in the file. Extern ProtoDeclares are stored in
scene files as ProtoDeclares. As such they should be able to use type
defined previously in their host file.

On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <andreasplesch at gmail.com
<mailto:andreasplesch at gmail.com> > wrote:

> Date: Tue, 26 Apr 2022 07:56:47 -0600
> From: GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com> >
> To: X3D Graphics public mailing list <x3d-public at web3d.org
<mailto:x3d-public at web3d.org> >

> When I started with freewrl around 2009, it had a text-based system for
> protos:
> - when parsing a scene, if it found a proto declare, it would scrape the
> text into a buffer. Then as it continued parsing, when it hit a proto
> instance it pasted, and continued parsing over the pasted text as though
it
> had been there all along. Extern protos similar, it would pause parsing,
go
> to the file referenced, look for the proto declare by name, and scrape out
> the text of the ProtoDeclare, for pasting in-scene.
> And it worked a bit. But especially extern protos weren't working
reliably.
> As a casual volunteer I decided to fix the bugs. How hard could it be? A
> little debugging and presto, I'd be a hero. As I got into it and saw more
> scene failure examples there were several emotional stages like grieving
> denial, shock, sadness, resistance etc. And a slow dawning realization the
> whole system needed a rework.
> And I didn't have support from others -just silence, perhaps they knew it
> was a mess and wanted to stay clear.
> It was a sickening feeling, and I needed to think for a few weeks whether
I
> even wanted to be a volunteer programmer if the system was rotten from the
> core.
> So it can not only be a monster task, but precisely because it's a monster
> there's little support for those brave enough to tackle it.
> (After a few weeks I got to the Acceptance stage of grieving, and spent 6
> months of hobby time building the new proto system).

Thanks for the story, and for engaging. To me, I became interested
when I realized that x3dom is probably flexible enough to allow for
parameterized definition and registration of new nodes dynamically
which behave then exactly like native nodes. This is different from
filling in templates. For example, there is no performance penalty
during tree traversal and it enables instancing using xml nodes with
the new names, just as in x3dv.

I am pretty happy with how it came out. An additional complication is
asynchronous loading of remote resources which is standard on the web.
X3D should rely less on how nodes or statements are ordered in a
scene.

It is just frustrating that there are ill defined corners. I really do
not think that proto declarations should be required to inherit
existing declarations from parent execution contexts ( DEF/USE name
scopes are different but there is still a separated execution context
). That means the protos array of a new execution context should be
empty initially. The SAI spec. actually says so.

Best, Andreas

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto: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/20220428/b4f8266d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220428/b4f8266d/attachment-0001.p7s>