> Mike writes:
> >What about modifications to other people's objects ?? I'd like to see the
> >reference to be parametized as well, I think, so I could reuse
parametrically.
(Mark writes ) ...
> I concur, but I think the best model is an assumption that *all*
> characteristics of an object are simply OO "slots" that can be
> over-ridden in an instantiation. Thus, one "slot" in the Refrigerator
> object would be "color". It would have a default, but if the
> instantiation gave a color, that would be used. I'm not hip enough
> on modern rendering technology to be sure how far you can push this,
> but I think it's an *excellent* paradigm to follow, and will
> encourage both standardization and creativity (because it will
> encourage people to use standard objects, and mess with them)...
Completely agree; I'm gonna jump on my (old) bandwagon again and say that
what **I** really want is a standard oo "renderactor" engine which has a
defined interface allowing me to instantiate 3-d objects, modify their
attributes, get their attributes, register to receive events of various types from
them when users interact with them, and destroy them. Also save/load these
objects from/to VRML textual descriptions sitting in URLs, etc. Behavioral
specification for the objects (including multi-user interactions) could be
handled by an external system which "gloms on" to the renderactor using the
interface, for example a conventional til/oo language or any other existing (or
new) system. This style of system allows tool writers to write some pretty
amazing stuff, being insulated from the concerns of parsing 3-d description
languages, renderers, etc. If the renderactor could pass out alien data to my
external app (when it loads objects from a URL) and store alien data (when it
writes to a URL) from my external app, so much the better. I could then use
VRML (or similar) to store my interaction code. { Sorry if this is out of the
area/scope }
Mike (tamarac)