1)
So far, we've arrived at the general agreement that we adopt
single inheritance system and interface notion to extend the
capability of our language system.
Now, I think, we should formulate the semantics and syntax of each
language element ,such as field, exposedField, eventIn, eventOut, and
CLASS and so on. However, in order to define the semantics of each
language element, we should agree on which basic strategy is chosen for
our language. Especially for CLASS and fields, I think, we should
agree whether we adopt the notion of 'path' or 'constraint system' into
our language or not. Unless we agree on this matter, I fear that our discussion
might go discursive or distracting.
In a former mail, I've suggested the notion of 'structural definition'.
I've worked around this idea and thought it might be sometimes useful.
We are currently considering 'path' or 'constraints'. I think these two
concepts are far more advanced form of 'structural definition'.
As you know, all these concepts give us many opportunities to accomplish
easily rather complex tasks that would require much more code or file.
For example, the following ROUTE
ROUTE the diffuse color of the material of my parent to the diffuse
color of my material
could be replaced by:
my_node {
diffuse_color PARENT.material.diffuse_color
}
Hence, we may eliminate may ROUTEs.
How about this ?
SFFloat X ...
SFFloat Y ...
SFVec3f A X Y 1.0
In summary, if we adopt the notion of 'path' or 'general constraints',
we can make VRML advance far more towards easy and efficient
construction of objects. The ROUTEs may be never required.
Hence, I think we should exchange each member's opinion on whether
this concept is deserved to be adopted, or good, or poor, or fantastic,
or just NOthing.
If we agree on this matter, we can proceed to the next stage: defining
the detailed syntax and semantics. Since we cannot make a debate or an
discussion at a comfortable restaurant, probably, we have to post
our opinion as systematically as possible. I wish your advice.
Currently, I am considering around embedding constraints into our language.
As soon as I arrange my proposal, I will post it.
2)
SUPER and PARENT : My intention was that PARENT indicates the parent node
in the graph hierarchy, and SUPER the super class. Anyway, I think
these must be redefined further.
3)
On Amulet : The innovative - the authors of Amulet assert that those
ideas are just 'innovative' and I agree to some degree - ideas in Amulet
may be applied to our new language. I think some of them can be directly
applied for us, such as 4 kinds of inheritance and others. However, I
recommend that while investigating on such systems as Amulet, we have to
keep in mind that our language is intended for real-time(frame-time ???)
applications. Hence, some good ideas may be inadequate for us.
4)
For anyone interested in using JavaScript translator, ask me.
Thank you.
-- So childlike in May !!!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sungwoo Park, (Castle-Help Naive)
homepage : http://compiler.kaist.ac.kr/~gladius
e-mail : gladius@compiler.kaist.ac.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -