[x3d-public] ProtoBody completeness in nested Protos

[GPU Group]

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> 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>
> 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/cba21711/attachment.html>