> From the previous mail (and the non-existence of objecting
> mails) I conclude, that the consensus is "Single Inheritance
> with Interfaces".
Good.
>
> I don't think we need SELF as in Sungwoo's examples:
> But we can make the inheritance implicit:
If we adopt the implicit inheritance strategy as with VRML 2.0,
we don't have to use SELF keyword. I agree that the implicit inheritance
is better for readability and compatiblity with VRML 2.0.
Then, we don't need EXTENDS keyword, either. Good.
> But Sungwoo confused me, when he said, we don't need IS.
> (Sungwoo could you reformulate your point, I tried
> hard, but did not understand your reasoning.)
My point was that if we keep the structural definition for each field,
then, the IS keyword is not required.
In VRML 2.0, when the IS keyword appears, only one parameter field should
be given. For example, in VRML 2.0, the following would be invalid.
PROTO [ field MFNode X ] {
Transform {
children IS [ A{} X ] # error
# However,
# children IS X
# would be correct.
}
}
> I think, the following should be valid:
>
> CLASS Toy [ eventIn SFFloat size ] {
> Transform {
> children [
> A { height IS size}
> B {}
> C {}
> ]
> }
> }
This code conforms to VRML 2.0 spec. I think we don't have to stick to
VRML 2.0 approach in this aspect.
>
> I also feel, that his example with the keyword SUPER (although I think,
> the basic idea is right), should not be valid, because it is
> difficult to implement:
>
> > CLASS HatRobot EXTENDS Robot [ exposedField SFFloat size 1. [ {
> > SELF {
> > children [ SUPER.children D{} ]
> > }
> > }
Note that in this example, SUPER.children is not a field value. (because
there is no specific super node.) Rather, SUPER.children indicates
the structure of the field of the super class.
>
> Which is equal to append(SUPER.children,[D{ }])
> The problem is, that in VRML we can not mix different values,
> there is no "append" operation for lists, no addition of
> integers, etc. Admittedly "append" could be implemented
> by using "addChildren". I suggest, we allow to use
> SUPER.propertyname as the only value of a field, not
> within a list: So the above example could be written as:
>
> CLASS HatRobot [ exposedField SFFloat size 1. [ {
> Robot {
> children [ Group { children SUPER.children }
> D{} ]
> }
> }
>
1)
First, let's re-examine the two examples.
One is as:
children [ SUPER.children D{} ]
The other is as:
children [ Group { children SUPER.children } D{} ]
I think the first is easier to understand. But it doesn't conform to
VRML 2.0.
The second conforms to VRML 2.0. But, I think, it is more complex and
harder to understand that the first one. Also, it may put unnecessary
inefficiency on the system performance.
To support the first case, we must treat implicitly MF types as
follows:
[ [ x y z ] w ] == [ x y z w ]
This may be a serious flaw with respect to type system.
However, the structural defintion of each type makes this problem
trivial. Additionally, if we adopt this strategy, the efficiency
will be increased.
The 'structural definition' approach would be best explained
by an example. If SFVec3f was defined as 'SFFlaot SFFloat SFFloat',
then, the following code would be accepted.
CLASS Test [ field SFFloat a 1
field SFFloat b 2
field SFFloat c 3
] {
...
# field sample is of type SFVec3f
sample a b c
# or
# sample [ a b c ]
This implies that it is not important whether brackets [ ] are
present or not. The reason is that the system only would have to
consider the structure of a field definition.
With this strategy, the implementation is, I think, no so hard.
It may show inefficiency when determining the value of a field
because we should go further into the sub-fields to determine
the final value of a field.
However, as is the 'children' example, there are some cases
where the system performace benefits from this.
I think this approach is very different from that used in VRML 2.0.
Someone may call it 'revolutionary change'.
I wish your opinion on this approach.
(Stephan said that the implementation would be hard. In my opinion,
it is not.)
>
> Sungwoo wrote:
> > Our discussion about eventIns and eventOuts
> > could be proceeded only after we've arrived at conclusion on whether
> > we would employ event handler strategy or ROUTE strategy.
>
> As we consider extensions of VRML here, I don't think it is
> a good idea to abandon ROUTEs. Why don't allow ROUTEs and
> say whenever possible use Eventhandlers. Both should work
> together. I understand, that you don't want ROUTEs in OOVRML.
> But that's because of your application (multi-user worlds).
> I think, we should try to combine dynamic routing with
> eventhandlers. In VRML 2.0 you can only route to
> a node which was bound to a name by DEF before.
> The idea of dynamic routing is, that you
> can route to a node, which you got as value of an
> eventIn or field. So you could write
>
> CLASS C [ field Interpolator node NULL ]
> { DEF X Transform { }
> ROUTE node.value_changed TO X.set_translation
> }
>
> So to promote Eventhandlers, we could integrate
> dynamic routing into them and not allow the
> above notation. So there is one reason
> more to use them. But again, I would still
> allow the old-fashioned VRML 2.0 ROUTEs.
>
2)
I think the event handler is much more related with Script nodes in
VRML 2.0 than ROUTES. My point in the previous mail was that
event handler strategy and 'Script node approach' cannot co-exist.
(Sorry for my inaccurate expression of my idea)
Actually, event handlers are irrelevant with ROUTEs. More importantly,
they don't depend on the semantices of eventOut. <- important !
In OO-VRML, I defined an eventOut as a set of eventIns. This is not
a necessary condition for employing event handlers at all.
This implies that both the event handler and the ROUTE can co-exist
without any problem, only if we keep the semantics of eventOut
as that in VRML 2.0.
However, I argue that we should eradicate nasty Script nodes from our
proposal. What is your opinion on this matter ??
As Stephan indicated, the ROUTEs give dynamic routing facility. I
think this increases the utility of any class greatly.
Summary:
please vote for only one from the following list:
1) ROUTE and Script node
2) ROUTE and Event Handler
3) No ROUTE and Event handler
I prefer 2).
After we get our consensus on this matter, let's suggest detailed
syntax and semantics.
>
> Now I come a last point: Interfaces
> sungwoo asked:
>
> > That is, I think that in INTERFACEs, there should
> > be no fields, exposedFields, or eventOuts. Is my idea right ?
>
> I disagree, I think interfaces should contain eventIns, eventOuts
> and fields. The difference is, that they should not contain default
> values for fields. These are provided by the class.
I've thought on this matter so much time. Could you explain
how we can solve the problem when there are more than one field
with the same name in different interfaces ?
>
> If we have interfaces, we might not have to introduce
> abstract classes. For example, we can define an interface
>
> INTERFACE ChildNode [ ].
>
> It defines no properties, but all child nodes have to
> implement it:
>
> CLASS Shape [ ... ] IMPLEMENTS ChildNode { ... }
>
> And we can use it for typing:
>
> CLASS Transform IMPLEMENTS GroupingNode
> [ exposedField MFChildNode children NULL ]
> { }
>
> Because Transform is a standard node, the body of
> the class definition has to be empty.
Okay. Then, what is the difference between Interfaces and
Abstract Classes ? I think if we allow fields or event{In,Out}s in
interfaces, then, we may be confronted with many problems of
multiple inheritance.
I will think again.
>
> I'd appreciate any feedback on the above ideas,
> they are just my opinions and these change from
> time to time.
>
> -- 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
> ---------------------------------------------------------------
>
Watch out COLD. Cold in the spring is annoying SO MUCH.
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -