<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules">https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules</a><br></div><div><br></div><div>"A prototype may be instantiated in a file anywhere after the completion of the prototype definition."<br></div><div><div>If the specs meant what you are suggesting --protos are self contained including proto definitions-- then it would have said "context" rather than "file"<br></div></div><div><div>"Prototype definitions appearing inside a prototype definition ( i.e., nested) are local to the enclosing prototype. "<br></div><div>- refinement of the above file order rule.</div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 26, 2022 at 9:51 AM GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">"I really do<br>not think that proto declarations should be required to inherit<br>existing declarations from parent execution contexts"</div><div dir="ltr"><br></div><div>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.</div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Date: Tue, 26 Apr 2022 07:56:47 -0600<br>
> From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>
> To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
<br>
> When I started with freewrl around 2009, it had a text-based system for<br>
> protos:<br>
> - when parsing a scene, if it found a proto declare, it would scrape the<br>
> text into a buffer. Then as it continued parsing, when it hit a proto<br>
> instance it pasted, and continued parsing over the pasted text as though it<br>
> had been there all along. Extern protos similar, it would pause parsing, go<br>
> to the file referenced, look for the proto declare by name, and scrape out<br>
> the text of the ProtoDeclare, for pasting in-scene.<br>
> And it worked a bit. But especially extern protos weren't working reliably.<br>
> As a casual volunteer I decided to fix the bugs. How hard could it be? A<br>
> little debugging and presto, I'd be a hero. As I got into it and saw more<br>
> scene failure examples there were several emotional stages like grieving<br>
> denial, shock, sadness, resistance etc. And a slow dawning realization the<br>
> whole system needed a rework.<br>
> And I didn't have support from others -just silence, perhaps they knew it<br>
> was a mess and wanted to stay clear.<br>
> It was a sickening feeling, and I needed to think for a few weeks whether I<br>
> even wanted to be a volunteer programmer if the system was rotten from the<br>
> core.<br>
> So it can not only be a monster task, but precisely because it's a monster<br>
> there's little support for those brave enough to tackle it.<br>
> (After a few weeks I got to the Acceptance stage of grieving, and spent 6<br>
> months of hobby time building the new proto system).<br>
<br>
Thanks for the story, and for engaging. To me, I became interested<br>
when I realized that x3dom is probably flexible enough to allow for<br>
parameterized definition and registration of new nodes dynamically<br>
which behave then exactly like native nodes. This is different from<br>
filling in templates. For example, there is no performance penalty<br>
during tree traversal and it enables instancing using xml nodes with<br>
the new names, just as in x3dv.<br>
<br>
I am pretty happy with how it came out. An additional complication is<br>
asynchronous loading of remote resources which is standard on the web.<br>
X3D should rely less on how nodes or statements are ordered in a<br>
scene.<br>
<br>
It is just frustrating that there are ill defined corners. I really do<br>
not think that proto declarations should be required to inherit<br>
existing declarations from parent execution contexts ( DEF/USE name<br>
scopes are different but there is still a separated execution context<br>
). That means the protos array of a new execution context should be<br>
empty initially. The SAI spec. actually says so.<br>
<br>
Best, Andreas<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
</blockquote></div>