[x3d-public] ProtoBody completeness in nested Protos

Thu Apr 28 21:00:33 PDT 2022

One can’t instantiate until after definition.  I’m fairly sure that covers
this case?  Maybe we can work with an example?

Thanks,

John

On Thu, Apr 28, 2022 at 9:23 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Thanks much for the review and revision effort.
>
> The recursive case brings up circular dependencies. Proto A may use an
> instance of Proto B, but Proto B in turn may use an instance of Proto A
> unless some initial condition occurs, so that in theory a result can be
> resolved.
>
> The recursive clause in a way covers this in my view but perhaps circular
> definitions could be made explicitly illegal.
>
> Just a thought,
>
> Andreas
>
> ---on the phone---
>
> On Thu, Apr 28, 2022, 8:45 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
>> We reviewed closely.  Prose definitions are correct.  Slight editorial
>> changes (essentially re-ordering sentences) hopefully make things clearer.
>>
>>
>>
>>    - Mantis 1395: improve clarity of prototype scoping rules
>>    - https://www.web3d.org/member-only/mantis/view.php?id=1395
>>
>>
>>    - -
>>
>>
>>    - 4.4.4.4 Prototype scoping rules
>>    -
>>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules
>>
>>
>>    - -
>>
>> A prototype may be instantiated in a file anywhere after the completion
>> of the prototype definition. Prototype definitions appearing inside a
>> prototype definition (*i.e.*, nested) have scope local to the enclosing
>> prototype. IS statements inside a nested prototype's implementation may
>> refer to the prototype declarations of the innermost prototype. A
>> prototype may not be instantiated inside its own implementation *(i.e.*,
>> recursive prototypes are illegal).
>>
>>
>>
>> A PROTO statement establishes a DEF/USE name scope separate from the rest
>> of the scene and separate from any nested PROTO statements. Nodes given a
>> name by a DEF construct inside the prototype may not be referenced in a USE
>> construct outside of the prototype's scope. Nodes given a name by a DEF
>> construct outside the prototype scope may not be referenced in a USE
>> construct inside the prototype scope.
>>
>>    - -
>>
>>
>>
>> Again thanks for all efforts to make the X3D4 specification clear and
>> consistently repeatable.
>>
>>
>>
>> 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:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> *Sent:* Wednesday, April 27, 2022 9:23 PM
>> *To:* GPU Group <gpugroup at gmail.com>; Andreas Plesch <
>> andreasplesch at gmail.com>; Richard F. Puk (puk at igraphics.com) <
>> puk at igraphics.com>
>> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org>; Brutzman,
>> Donald (Don) (CIV) <brutzman at nps.edu>
>> *Subject:* RE: [x3d-public] ProtoBody completeness in nested Protos
>>
>>
>>
>> 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> 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
>>
>> _______________________________________________
> 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/20220428/ff4db787/attachment-0001.html>