[x3d-public] ProtoBody completeness in nested Protos

[GPU Group]

"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>
wrote:

> > Date: Tue, 26 Apr 2022 07:56:47 -0600
> > From: GPU Group <gpugroup at gmail.com>
> > To: X3D Graphics public mailing list <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
> 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/20220426/71344266/attachment.html>