1)
I treated eventIn's just as tags for event handlers up to now. That is,
I intended that they should be used only to indicate event types.
>From your comments, I found it was a reckless decision.
Hence, if we adopt event handler approach, we should specify whether
eventIn's are regarded as data or not.
If we treat them as data, then, as you indicated, re-declaration of
the eventIn is unnecessary. Else, we re-declare it.
Which is the better ??? (Note: PROTO == CLASS in VRML++)
Candidate 1)
PROTO NewRobot extends Robot [
eventIn SFInt32 X
] {
HANDLER X {
url "vrmlscript:
function main(c,t) { ... }
"
}
}
Candidate 2)
PROTO NewRobot extends Robot [
] {
HANDLER X {
url "vrmlscript:
function main(c,t) { ... }
"
}
}
In my opinion, the second is better because it is natural to consider
eventIn's as data such as eventOut, field.
2)
In the above example, the handler X receives events of type SFInt32.
If a new event handler X which receives events of type SFFloat
is to be defined in NewRobot, we must declare explicitly a
corresponding eventIn as shown below:
PROTO NewRobot extends Robot [
eventIn SFFloat X
] {
HANDLER X {
url "vrmlscript:
function main(c,t) { ... }
"
}
}
Then, the previous event handler X which processes SFInt32 events is lost.
Is it a serious problem, or is it OK to ignore it ???
Thanks. My sleeping time AM 8:00 has come. I go...
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -