The following is my first impression for Amulet. I've no practiacal
experimemts of Amulet to make a real application, so I may have
misunderstood some ideas.
However, I concentrated on how we could bring useful ideas in Amulet
to our language while studying the material.
>What is very interesting with Amulet is the fact that you have a
>prototype
>instance object system integrated with constraints. Amulet objects are
>not typed. They are defined by a prototype and a set of local slots
>(fields).
>Objects are created by creating a empty object that has for prototype an
>existing objects. Initialising the system consists in creating the set
>of
>basic prototypes that will serve to create new objects.
>Every slot which is not found locally is searched by delegating the
>request
>to the prototype. Creating a new object is done by creating an empty
>object that will delegate all data requests to its prototype. Amulet's
>objects
>only have one prototype, but we could add multiple inheritance by
>allowing multiple prototypes or parent slots.
>
1)
We may contrast Amulet's prototype-instance system with VRML
prototype-instance system. The literature says that in a prototype-instance
system, there is no distinction between classes and instances. That is,
every object can serve as a prototype for other objects.
If we would apply this idea to VRML, we could write the following pseudo
code:
PROTO P_X [..] {..} # prototype
DEF X P_X [..] # new object X from prototype P_X
DEF Y X [..] # new object Y from object X
# note DEF instead of USE
I think DEF/USE architecture in VRML 2.0 resembles this idea, althought
DEF/USE in VRML is very primitive compared to general prototype-instance
systems such in Amulet. So, if we want our language to marry
prototype-instance system, I think, we only have to refine the semantics of
DEF/USE which is currently used in VRML.
Additionally, we cannot disregard the well-defined prototype systems in VRML
2.0. Those basic nodes in VRML 2.0 were chosen very carefully. (The
employees in Silicon Graphics Co. may try to eradicate this working
group if we argue that the nodes in VRML 2.0 must be useless.)
Anyway, I wish your comments.
>Each slot may contain some data or a method. The type of values
>that are contained in slots is not determined and can evolve at
>run-time.
>Which slots are installed in an object can also evolve at run-time
>allowing to enrich individual objects with richer behavior or to modify
the behavior of the object depending on the execution context.
>
>The value of slots (containing methods or slots) can be computed by one
>or several constraints. Amulet offers two constraint solvers, one for
>one
>way constraints and the other one for smooth transitions between
>successive
>values. In Amulet, it is very easy to write a constraint. You just write
>a routine that returns the value and then you install it in the slot.
>All
>the slots that are traversed during the evaluation of the routine are
>marked as dependencies. If the value of any of these slots changes, then
>the constraint is mark invalid and is reevaluated. During reevalution, a
>new dependency list is built from the slots being traversed. It may be
>totally different from the previous one.
2)
The notion of constraint seems to be very useful for our language.
(I am not sure yet whether the 'path' is included in 'constraint' or not.)
Also, the idea of no distinction between methods and data seems to be
even better.
I guess the following code can be valid if we adopt this strategy.
SFFloat Y
SFFloat X cal_X() { return Y + 1.0; }
or
SFFloat X cal_X(param = Y) { return param + 1.0; }
However, in my opinion, the strict dependency checking may be unnecessary,
especially for 'invalidating' slots and others. The reason is that the
target system of our language is dynamic(not static) 3D virtual world system
which renders the world scene frame by frame. We only have to check the
dependency list at the start time of the world, and use the result on each
frame rendering stage, and add minor changes to the dependecy list as
the world changes. This situation seems to be different to those in
classical user-interface applications.
>
>For having worked with VB2 and Amulet extensively (i3d v2.0 and v3.0 are
>built using Amulet), it is my feeling that for a langage like VRML, the
>concepts that are in Amulet (prototype-instance object models integrated
>with one-way constraints with automatic dependencies) is exactly what we
>need. Prototypes and slots maps well with nodes and fields, while
>one-way
>constraints maps well with clever routes.
3)
(I am sorry for my strong argument.)
I dislike ROUTEs. While developing OO-VRML, I expelled ROUTEs from VRML.
Don't you think that employing contraints and some minor changes to
eventOut and eventIn makes ROUTEs unnecessary ???
>
>In VB2, the role of paths was to build the dependency list. Paths are
>not
>needed in Amulet. They are integrated in the routine code that
>implements
>the behavior of the constraint. For the programmer, the Amulet solution
>is much more easy.
>
>Now, when it comes to having a PARENT slot, you will have to think about
>multiple instances of a node in the graph. That is the main reason why
>you
>are not able to go up the graph in OpenInventor and VRML.
>In i3d v3.0, multiple instances are obtained with multiple objects
>sharing the slots that corresponds to VRML fields. That way, I can
>maintain all kinds of information that depends on the position in the
>graph, like the parent, the global transform.... I call these sharing
>groups. The promotion/depromotion of an object to/from a sharing group
>is done automatically simply by declaring the VRML slots as shared/local
when
>you add/remove the children to nodes. That's a good example of the power
>of prototype-instance systems where objects can change their behavior at
>run-time.
4)
The idea of 4 kinds of inheritance in Amulet is very interesting, and good.
I suggest they should be considered for incorporating into our language.
The drawback, I think, is that we have to devise new keywords to denote
which kind of inheritance is used for a given field. Hence, we may have to
write as:
LOCAL Field SFFloat X 1.0
SHARED Field SFFloat Y 1.0
COPY Field SFFloat Z 1.0
and others...
This will make the language far more complex.
Thank you.
-- So childlike in May !!!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sungwoo Park, (Castle-Help Naive)
homepage : http://compiler.kaist.ac.kr/~gladius
e-mail : gladius@compiler.kaist.ac.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -