Re: On Inheritance...

Park SungWoo (gladius@compiler.kaist.ac.kr)
Thu, 10 Apr 1997 03:47:01 +0900 (KST)

>
> Park SungWoo wrote:
>
> > 1)
> > Now, we want to define a new prototype similar to Robot, let's call it
> > NewRobot. A NewRobot node has the same structure as Robot nodes. However,
> > its event handler X actly slightly differently to Robot's handler X.
> > Consider the following code :
> >
> > PROTO NewRobot extends Robot [
> > eventIn SFInt32 X
> > ] {
> > HANDLER X {
> > url "vrmlscript:
> > function main(c,t) {
> > // compute new 'rot' according to SFInt32 c
> > // rot = g(c) for some function g()
> > // g() != f()
> > }
> > "
> > }
> > }
> >
> > Class NewRobot has two fields, rot and clr, both of which are inherited
> > from its super class Robot. Class NewRobot has overridden its superclass'
> > handler X.
> > Then, my question: In this proposal, prototype NewRobot declared
> > eventIn SFInt32 X. Is is necessary ?? To Omit it is better ??
> >
> The thing that makes this hard to answer I think is that redeclaring the
> "HANDLER X" overrides the base class "HANDLER X", but declaring

1)
In class NewRobot, we want the HANDLER X to be redefined. Hence, as you
may think, the re-declaration of eventIn X is redundant and unnecessary.
Then, prototype NewProto would be shown as below.
What I fear about is that in this case, the prototype NewProto may
be sometimes confusing. For, at first glance, there is no corresponding
eventIn declared. Am I right?? or is it just groundless fear ???

PROTO NewRobot extends Robot [
] {
# only redefines HANDLER X
HANDLER X {
url "vrmlscript:
function main(c,t) {
// compute new 'rot' according to SFInt32 c
// rot = g(c) for some function g()
// note that g() != f()
}
"
}
}

> something else like the "Transform.." is not overriding the base class
> Transform (is that correct?).

2)
Yes, you're exactly right. In this approach, we can only redefine event
handlers. We can't re-write the content of Transform node. I think
it is a serious problem.
In a subclass definition, we can only add new nodes to the base class' nodes.
To be specific, consider the following case.

class X [ eventIn SFInt32 P ] {
Transform {...} # let's call this Transform{} T1
HANDLER P {...}
}

class Y extends X [] {
Transform {...} # let's call this Transform{} T2
HANDLER P {...}
}

We could redefine event handler P. However, we couldn't redefine the structure
of Transform{} T1. Transform{} T2 is only added to the base node description.
Hence, class Y has actually two nodes, namely, Transform{} T1 and
Transform T2{}.
In summary, we can't redefine a node in our current idea (I think so).
But in some other light, it is unnecessary.
If we want to redefine Transform{} T1 in class Y, then why should we
extend class X to declare class Y ???
We only have to just define a new class directly.
I wish your opinion on this point.

>
> What would make it less confusing, at least to me, would be if the
> HANDLER X syntax looked like code instead of nodes..., like
>
> vrmlscript function handler_x(c,t) {
> // compute new 'rot' according to SFInt32 c
> // rot = g(c) for some function g()
> // g() != f()
> }
>
> If it looked like this, then it would be like C++ or Java in that you
> can tell data from code by the syntax. In that case, it would be easy
> to say you don't need to declare the "eventIn".

3)
In your suggestion, function handler_x() encapsulates the event handler.
In OO-VRML, HANDLER X{} is employed for the event handler.
So, I think there is no fundamental difference between two approaches.
However, we can write the script code in Java or else. Besides that,
the event handler may want some subsidiary functions for main() or
some local fields for temporary computational results. Hence, I think
HANDLER approach shows no serious problem.

>
> JJ
>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
 Sungwoo Park, (Castle-Help Naive)
	homepage : http://compiler.kaist.ac.kr/~gladius
 	e-mail : gladius@compiler.kaist.ac.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -