[x3d-public] set_/_changed pre/suffix History [was: set_Value prefix and value_changed suffix]

[Leonard Daly]

I am going to attempt to provide some historical perspective to set_ and 
_changed event names. Unfortunately, my memory has a few holes. This is 
just a (partial) recounting of history and not a claim that the language 
in the document was correctly provided to fully capture the intent of 
the participants.

Way back when working on X3D V3[.0] there was a long discussion on this 
topic. The concern was trying to be really clear in the language 
definition so that an unambiguous DTD could be written and the user 
create valid XML. The particular concern was inputOutput fields in 
Script nodes.

Using Michalis' example of the 'on' inputOutput field in a light node. 
If the user code is:

    <Script DEF='Foo' >
         <field name='on' type='SFBool' accessType='inputOutput'/>
         <field name='bar' type='SFInt32' accessType='inputOnly'/>
    ![CDATA[ecmascript:

    function on (value, time) {
         ... do something...
         on = !on;        // !!!
    }

    function bar (value) {
         on = (value == 2);
         return on;
    }
    ]]>
    </Script>


You can ROUTE events to Foo.on, store a value in it, and ROUTE events 
from Foo.on. It is not clear what to do with each occurrence of 'on' and 
how that might be valid XML and ECMAScript.

This makes a true mess of code. I think a similar thing happens with PROTO.

The solution was to require set_ and _changed for certain conditions 
(like Scripts) and maintain some flexibility in dealing with existing 
inputOuput fields (e.g., on from DirectionalLight). The above example 
should be written as:

    <Script DEF='Foo' >
         <field name='set_on' type='SFBool' accessType='inputOnly'/>
         <field name='on_changed' type='SFBool' accessType='outputOnly'/>
         <field name='on' type='SFBool' accessType=''/>
         <field name='bar' type='SFInt32' accessType='inputOnly'/>
    ![CDATA[ecmascript:

    function set_on (value, time) {
         ... do something...
         on = value;        // !!!
    }

    function bar (value) {
         on = (value == 2);
         on_changed = on;
         return on_changed;
    }
    ]]>
    </Script>


In this example the meaning and operation of each occurrence if '*on*' 
is clear and there is no problem with the ECMAScript. '*on*' is either a 
function ('set_on'), an internal variable ('on'), or an output 
('on_changed').


Leonard Daly




> 2017-04-24 15:38 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
>> But these are input_only and output_only fields, not inputoutput fields.
>> Here is the spec. follows (satisfyingly) its own recommendation from 4.4.2.2
>> Field Semantics, items h) and j).
>>
> Reading the Andreas mail, I realized that my testing
>
>    ROUTE MyTimeSensor.fraction TO MyPositionInterpolator.fraction
>
> vs
>
>    ROUTE MyTimeSensor.fraction_changed TO MyPositionInterpolator.set_fraction
>
> was not very useful: there is no inputOutput called "fraction" here,
> so it's normal that the 1st form doesn't work.
>
> The correct testcase of the question "is set_/_changed required to
> refer to inputOutput fields as events" is to compare:
>
>    ROUTE MyTimeSensor.isActive TO MyLight.on
>
> vs
>
>    ROUTE MyTimeSensor.isActive TO MyLight.set_on
>
> Here, we test X3DLightNode.on (inputOutput field). A simple testcase
> using this is attached.
>
> Testing on my own view3dscene, we support both forms. So it looks like
> I was wrong (two times!):
>
> 1. "Me from the past" understood the specification to mean "the
> set_/_changed are *optional* if you want to refer to inputOutput field
> as event". Just like it is more sensible to Andreas.
>
> 2. "Me from the past" implemented view3dscene to make them optional.
>
> Sorry for the confusion:)
>
> Regards,
> Michalis
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170424/dbeb5fe4/attachment-0001.html>