(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 ???
The body of the function definition has local variable definitions, and
they do not conform to VrmlScript (or javascript) syntax.
FUN SFVec3f distance [ ... ]
{
SFVec3f newpos 0 0 0; <-------- strange
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;
}
(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.
(4)
You mentioned that 'indirectly reference objects' may cause a major
technical problem in implementation.
I think that is an implementation issue, not a language issue.
So, I think the semantics of path expressions deserves more attention.
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 ?
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 ???)
(To solve this problem, I tried to instantiate any object whenever it is
referenced to by other object in OO-VRML.)
(5)
I suppose that the semantics of SELF and PARENT is reasonable if
the constraint system is built on VRML.
But, if we adopt node type system (or subclassing), the semantics may
not be valid.
Thank you.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sungwoo Park, (Castle-Help Naive)
homepage : http://compiler.kaist.ac.kr/~gladius
e-mail : gladius@compiler.kaist.ac.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -