[x3d-public] unconnected proto fields
Richard F. Puk
puk at igraphics.com
Sat Oct 24 12:57:52 PDT 2020
Hi, Michalis --
If a field is specified in the prototype declaration but is not used in the prototype body, the field should behave like a noop (i.e., as if it was not specified).
-- 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: Michalis Kamburelis [mailto:michalis.kambi at gmail.com]
Sent: Saturday, October 24, 2020 12:00 PM
To: Richard F. Puk
Cc: Andreas Plesch; X3D Graphics public mailing list
Subject: Re: [x3d-public] unconnected proto fields
Richard -- agree with everything you say. Prototype declaration must
specify all fields fully (including defaults), and when instantiating
prototypes -- you either specify a field value, or the default is
used.
But the question from Andreas that started this thread touches a
little different problem, It's about "what if the prototype declares a
field, but field remains unused in ProtoBody (implementation of the
prototype)". Expressing this in X3D classic encoding, consider this:
"""
PROTO MyShape [
inputOutput SFNode geometry Sphere { }
inputOutput SFColor color 1 1 0
] {
Shape {
appearance Appearance { material Material { } }
geometry IS geometry
}
}
"""
The question is: what should the browser do about "color"? It is
unused by the prototype implementation. In the above example, it is
likely just a mistake of the author who forgot to write "diffuseColor
IS color" (although higher in this thread I mention some cases when a
field may be unused, but it's not a simple mistake). Should we just
silently ignore this fact, or do something (like a warning or more).
Regards,
Michalis
I think we discuss a bit different question wirth
sob., 24 paź 2020 o 08:47 Richard F. Puk <puk at igraphics.com> napisał(a):
>
> 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