Re: Still Alive

Stephan Diehl (diehl@cs.uni-sb.de)
Fri, 11 Jul 1997 15:38:07 +0200

Park SungWoo wrote:
>
glad to
> meet you.
>
> ... The one is writing the
> specification (an informal introduction) of a new language.
> You can read what I am writing at
> http://compiler.kaist.ac.kr/~gladius/oovrml/spec.html
> It describes some features of the language unsystematically. The document
> is being updated continually.

Good job! Above all I like the idea of instantiating
classes and objects as in

CLASS A [] {}
DEF B A {}

A { }
B { }

As your are in the process of writing the specification,
there a still many points missing, e.g. the syntax of
constraints.

You write:
" Any incoming event for the field are ignored because
only the constraint is used to determine its value. "

I don't think, this is the way it should work. I expect,
that there could never be the case that an event is
routed to a field and a constraint is attached
to a field at the same time. A route would remove
the constraint and vice versa, depending on which
one is created last.

If I understood the syntax of class declarations right,
there is no body of a class definition where one
could just add node instances. I try to make this
point clear by giving an example:

in VRML 2.0

PROTO A [ field SFFloat size 10 ]
{ DEF CYL Cylinder { height IS size }
DEF CLOCK TimeSensor { }
ROUTE CLOCK.fraction_changed TO CYL.size
}

in your syntax there is no place to define the TimeSensor:

CLASS A [ field SFFloat size 10
transparent field SFFloat radius
... and all other external fields of Cylinder
]
EXTENDS Cylinder
[ height size ]

There is another problem with this syntax, namely that
one has to declare every inherited field transparent.
Usually in OO fields are accumulated by inheritance
and in your terminology all inherited external fields
of a superclass become external fields of the subclass.

Consider the following example:

CLASS A
CLASS B EXTENDS A
CLASS C EXTENDS B

If we add a field f to A we would have to add "transparent"
declarations into B and C. Eventually it leads to huge
class definitions consisting mostly of transparent declarations,
e.g. the definitions in the VRML97 paper of Curtis Beeson.
So I would suggest a keyword hide which would do exactly
the opposite of transparent. hide would turn an inherited
external field into an internal one.

Good luck for your finals!
-- 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
---------------------------------------------------------------