Park SungWoo wrote:
>
> (1)
> I want to hear you about the accessibility of fields and exposedFields
> in paths.
> If a node pointer X is available, then, are every field, exposedField,
> eventIn, and eventOut of the node referenced to by X accessible ?
Yes, but it is only possible to read these values, because paths
can only occur as field values. We cannot write
DEF NODE SomeNode { ... }
NODE.someField = ...
In this case, one would have to distinguish writeable and readable
fields:
a field of type FIELD is readable only
EXPOSED is readable and writeable
EVENTIN is writeable
EVENTOUT is readable
>
> (2)
> The functiondef construct seems to have a suitable structure.
>
> Is the scope of the function name global or avaiable only after the function
> is defined ???
GLOBAL !
>
> The body of the function definition has local variable definitions, and
> they do not conform to VrmlScript (or javascript) syntax.
I think they conform to the Scripting syntax. There are two kinds of
variables, those which you don't declare and do not survive the
execution of the function and those which are persistant. They
are defined in a Script node as fields, exposedFields and so on:
Script { exposedField SFTime startTime 0
exposedField SFInt32 counter 0
eventIn SFInt32 someFunction
url "javascript: function someFunction(value,ts)
{ counter = counter+1;
i=counter;
return i;
}"
}
As a function definition this would be encoded as:
FUN SFInt32 someFunction [ SFInt32 arg1 ]
{ SFInt32 Counter 0;
counter = counter + 1;
i=counter;
return i;
}
Here i is a local variable and counter is persistent.
>
> FUN SFVec3f distance [ ... ]
> {
> SFVec3f newpos 0 0 0; <-------- strange
Its a mixture of VRML and C/Java syntax.
>
> newpos[0] = ..
> ..
> return newpos;
> }
>
> How about inventing a new functiondef construct which separates the local
> variable definitions and the programming code. For example,
>
> FUN SFVec3f distance ( SFVec3f pos1
> SFVec3f pos2 ...
> SFFloat z ) [
> SFVec3f newpos 0 0 0
> ] {
> newpos[0] ...
> ...
> return newpos;
> }
Yes, I think this is a good solution!
>
> (3)
> The grammar for 'path' allows multi-level function expressions.
> ex)
> x = f1(p,q,f2(r,s,f3(a,b,c)))
>
> If we don't want to adopt these expressions, then, I think
> that the grammar for 'path' should be slightly changed.
>
> x = y.z.w
>
> can be conceptually changed into
>
> x = equal(y.z.w)
>
> Hence, 'fieldvalue' only have to include a 'function expression' for
> constraints.
This would at least make the implementation easier.
>
> (4)
> You mentioned that 'indirectly reference objects' may cause a major
> technical problem in implementation.
Once again, we have to different approaches. As I want to
implement the language on top of VRML I always have to
think on how to implement the extensions.
> I think that is an implementation issue, not a language issue.
> So, I think the semantics of path expressions deserves more attention.
I agree, I read the section in your proposal. I think, that PARENT
should be a MF-type field. So if the scene graph is a DAG we
get a list of parents and using the dynamic routing introduced
in VRML++ one could for exampel route events to each parent.
>
> Consider the following example.
>
> DEF CHILD { fld01 = PARENT.translation }
>
> DEF T1 { children [ USE CHILD ]
> translation 0 0 0 }
>
> DEF T2 { children [ USE CHILD ]
> translation 1 1 1 }
>
> a. How many instances of CHILD node should the system maintain ?
In your proposal there would be 3 copies of the CHILD node.
> b. If no node refers to CHILD node, then, how is the value of fld01 of CHILD
> determined ? (This is an example of indirectly referenced object problem ???)
It would be NULL and changed as soon as the node is but somewhere in the
scene graph and gets a parent.
>
> (To solve this problem, I tried to instantiate any object whenever it is
> referenced to by other object in OO-VRML.)
as you know, this will consume much more memory
>
> (5)
> I suppose that the semantics of SELF and PARENT is reasonable if
> the constraint system is built on VRML.
Yes, the semantics will be translational, i.e. given by the way
the extensions are translated into VRML. But this translation
should be intuitive for VRML authors.
> But, if we adopt node type system (or subclassing), the semantics may
> not be valid.
Yes, I agree, but I tried to separate OO and types from the constraints.
Types will help to detect errors in the constraints at compile-time
as they did in VRML++.
I think, in a final proposal of our working group we have to integrate
these again. But for the moment I chose a divide-and-conquer approach.
Reading your proposal, I found that we are diverging, as you suggest
a syntactically completely new language and I still try to extend VRML.
Cheers
-- Stephan
---------------------------------------------------------------
Dr. Stephan Diehl Tel.: ++49-681/302-3915
EMAIL: diehl@cs.uni-sb.de WWW: http://www.rw.cdl.uni-saarland.de/private/diehl
---------------------------------------------------------------
There is no place like $HOME
---------------------------------------------------------------