[x3d-public] unconnected proto fields

Richard F. Puk puk at igraphics.com
Fri Oct 23 23:47:02 PDT 2020


Hi, Michalis --

It seems to me that the correct answer should be that prototype declarations should be well-formed as are specified nodes. This means that all field in the prototype declaration should be fully specified. However, a prototype instance should behave like any other node so that an author can choose to use a field or not. If the field is not used by the prototype instance, the underlying "node" should use the default value for that field.

  -- Dick

/******************************************
| Richard F. Puk, Ph.D., President
| Intelligraphics Incorporated
| 7644 Cortina Court
| Carlsbad, CA  92009-8206
| Tel: +1-760-753-9027  Mobile:  +1-760-809-9027
| Email:  puk at igraphics.com
\****************************************** 



-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Michalis Kamburelis
Sent: Friday, October 23, 2020 2:17 PM
To: Andreas Plesch
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] unconnected proto fields

I got my head stuck with the analogy """unused ProtoInstance field is
a similar situation to an unused routine parameter in normal
programming language""" :) That is why I wrote "parameter". Indeed
"field" seems a proper nomenclature when it comes to prototypes.

In general I agree that the warning may be useful in some situations.
But I don't think this is the choice of the browser, to decide "this
is definitely invalid because the field is unused". The author may
choose to expose an (ignored) field in their prototype.

In the use-case of "backward-compatibility", I can imagine either
decision making sense. Maybe the author doesn't have control over some
model using the prototype, so it is better to keep the old model
somewhat working (but with some field ignored) than to break it (by
removing the field from the prototype in another file)?

Regards,
Michalis

pt., 23 paź 2020 o 20:49 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> I was not sure if connecting is actually required or not. Often being
> more strict seems to be the preferred option.
>
> The underlying reason for being more strict about connecting is that
> x3dom needs to know the type of the field in case of node value fields
> when it registers the new node as an available x3d node.
>
> Just like the signatures in the spec. spell out the type of node fields.
>
> But what can be done is just using a default type of X3DNode for
> unconnected fields, and then otherwise ignoring the field.
>
> > - maybe it was implemented one day, and it no longer works, but it
> > remains declared for 100% backward compatibility of the API? I.e.
> > author doesn't want to break existing EXTERNPROTO usage of the PROTO,
> > so it is better to leave an unused PROTO parameter.
>
> I see that as a situation where it would be much better to have a
> warning or to fail to alert the user of the extern proto that the
> field that the instance is still using is actually not available
> anymore. Silence could lead to much soul searching and frustration.
>
> Also, is it not more accurate to refer to the ProtoInstance fields as
> fields rather than parameters ?
>
> cheers, -Andreas
>
> On Fri, Oct 23, 2020 at 1:58 PM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > I would say "Silently ignore" is what should be done. Specification
> > doesn't require that all prototype parameters are used.
> >
> > Some optional 'hint" from a browser ("the parameter xxx is unused")
> > may be helpful, but I would not call it a "warning". It may be a valid
> > situation. It's just like having a routine in any programming language
> > with an unused parameter: it is allowed, and sometimes it makes sense
> > (even when it's not a virtual method or a callback, where parameters
> > are forced to satisfy external requirements).
> >
> > Example when it makes sense:
> >
> > - maybe the author declares some prototype parameter, but has not
> > "implemented" it yet in the prototype? E.g. I have a PROTO "Car" where
> > I expose "SFColor color", but it's not yet implemented, and the
> > prototype always expands to a black car?
> >
> > - maybe it was implemented but is temporarily commented out?
> >
> > - maybe it was implemented one day, and it no longer works, but it
> > remains declared for 100% backward compatibility of the API? I.e.
> > author doesn't want to break existing EXTERNPROTO usage of the PROTO,
> > so it is better to leave an unused PROTO parameter.
> >
> > Regards,
> > Michalis
> >
> > pt., 23 paź 2020 o 19:45 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
> > >
> > > A ProtoDeclaration may have fields in the interface definition which
> > > are then not connected to any fields or nodes in the ProtoBody.
> > >
> > > This is usually not the case since it does not seem to serve a
> > > purpose. Nonetheless authors may inadvertently define such unconnected
> > > fields in a ProtoInterface.
> > >
> > > Is there a requirement for such a connection ?
> > >
> > > Could there be a sensible use case for unconnected Proto fields ?
> > >
> > > How should a browser react to this?
> > >
> > > Silently ignore ? This is apparently the behaviour of many X3D
> > > browsers currently.
> > > Fail early ? To prevent any subsequent problems flowing from such an
> > > occurrence ? This is what x3dom currently does.
> > > A warning ? Seems reasonable unless there is a spec. requirement.
> > >
> > > -Andreas
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
> > >
> > > _______________________________________________
> > > x3d-public mailing list
> > > x3d-public at web3d.org
> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org




More information about the x3d-public mailing list