>From the previous mail (and the non-existence of objecting
mails) I conclude, that the consensus is "Single Inheritance
with Interfaces".
I don't think we need SELF as in Sungwoo's examples:
> CLASS Toy EXTENDS Transform [ ] {
> SELF {
> children [
> A {}
> B {}
> C {}
> ]
> }
> }
But we can make the inheritance implicit:
CLASS Toy [ ] {
Transform {
children [
A {}
B {}
C {}
]
}
}
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.)
I think, the following should be valid:
CLASS Toy [ eventIn SFFloat size ] {
Transform {
children [
A { height IS size}
B {}
C {}
]
}
}
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{} ]
> }
> }
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{} ]
}
}
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.
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.
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.
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
---------------------------------------------------------------