Re: Subtyping and Subclasses

Johannes N. Johannsen (jojo@well.com)
Fri, 11 Apr 1997 11:34:50 +1200

Stephan Diehl wrote:
>
> 1) A is a subtype of B <=> A has all properties of B
>
> In VRML properties are events and fields. (There is also
> another property, namely that certain nodes can only be
> used at certain positions, e.g. only child nodes as the
> values of the children field. But we hope, that these
> restrictions verbally expressed in the VRML spec,
> can be explicitly defined with the help of the type system)
>
As Stephan mentions here, the VRML spec is sort of object oriented,
except it expresses that class hierarchy verbally, rather than as part
of the grammar syntax. So once you have your parser, you still have to
do the remaining work constructing that class hierarchy. Here is what
I've determined is the class hierarchy:

SFNode
Material
Texture
ImageTexture
MovieTexture
PixelTexture
TextureTransform
Color
Normal
TextureCoordinate
Appearance
Geometry
Box
Cone
Cylinder
ElevationGrid
Extrusion
IndexedFaceSet
IndexedLineSet
PointSet
Sphere
Text
Sound
AudioClip
MovieTexture
Coordinate

Now I've left out some derived from SFNode, and some of the above don't
have subclasses so they might appear similar to the ones I left out.
But the difference is that there are fields that MUST contain a specific
type, like Coordinate (i.e. a verbally expressed data type). Also, you
have to have these as a data type, because the field restriction rules
apply to PROTOs, since the first node in a PROTO could be considered the
base type.

This sort of thing has to be a requirement, because authoring tools and
users really have no flexibility in the types. Everyone has to go to
the spec to see the "real" type.

Also, I've left out grouping nodes. I'm still a bit confused about
these. You could say there is a base class for everything that contains
a set of nodes, which would pretty much make Group the base class, and
Anchor, Billboard, Collision, and Transform subclasses of it. But there
is nothing that requires that data type. And in an authoring tool, you
might need to change one type into another (say convert a Group to a
Transform), so from that point of view, maybe it would be better to
consider Group a restricted subclass of Transform. There seems to be
alot of emphasis on extending behavior, and I'm still not sure how often
or useful restricting it is. But it is normal in OO programming to do
both (extend or restrict) in subclasses. So this is the source of my
confusion.

JJ