[x3d-public] unconnected proto fields

[Andreas Plesch]

Declared but unconnected fields could be used as documentation of
sorts, or as hints for future functionality. But there are comments or
meta fields as well.

To me, exposure would apply more to the fields the implementation
uses. These can be exposed through ISing to Proto fields.

Well, x3dom can have a warning on the console during registration, and
there will be another one anyways when there is an assignment of a
value from the instance because it cannot be applied to a connected
node.

Thanks, -Andreas

On Fri, Oct 23, 2020 at 3:18 PM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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



-- 
Andreas Plesch
Waltham, MA 02453