That's what they're currently doing. I am questioning whether that's
the *right* way for such things to work. We certainly need to do this
in a way that automated modelers can handle -- but there's nothing
even slightly difficult about having a user specify that this thing
he's designing is an IceCreamCone, that it has the following params,
and that those params get used in the following way. Yes, it's spitting
out some low-level shapes; that doesn't preclude it from including some
high-level information as well.
More on this below...
>A RISC/CISC analogy can be made here. RISC architectures are created to make
>it easy on the compiler writers. CISC architectures were created to make it
>easier on assembly language programmers.
>
>Lets make it easy to create VRML compilers (== modelers). I know we're at
>the assembly language (== create .wrls using vi/emacs) stage, but lets design
>for the future.
An interesting analogy, but you can't push it too far. RISC
architectures are comparatively simple, but they are also highly tuned
to the needs of a real system. It isn't just trimmed back to the
simple assembly language of the early days -- it's an instruction set
that is designed to meet the sophisticated needs of modern
computing. Which means some things that are simple, and some that
(while simple and fast) are really only *useful* in a smart and
sophisticated context.
In other words, a modern RISC machine isn't primitive -- it simply
has stripped out that stuff that can be done better at a high level.
It isn't clear to me that VRML 1.0 has all the *basic* functionality
we will need in the long run, in order to write those higher-level
tools.
Or in other words: it's hard to write efficient, powerful indirect
function calls in your high-level language if your processor doesn't
at *least* understand stack frames.
Robert writes:
>Additionally, I *do* think creating classes or types is a little much, at
>least at the moment.
While you're correct for the moment, I think we're going to need them,
and sooner than may be obvious.
I'm trying to understand the whole picture of what a VRML 2.0 system
is going to look like. (Note that all of this is probably premature
for 1.1, but as I've said before, we need to start codifying 2.0
*now*, because it's going to take months to work out, and many more to
implement.) The following is a very rough sketch of some very rough
thoughts.
We are dealing with an application that is intrinsically *highly*
object-oriented. The end user (that is, the average scene designer) is
going to be relatively unsophisticated, but is going to want to be
creating non-trivial scenes, with interactivity and behaviour. How do
we support this?
There is going to be an obvious market for *widgets*. We'll be wanting
to develop small packages that comprise a "physical" object, plus some
behaviour code that goes with it. Those objects need to have
relatively well-defined, parameterizeable interfaces (both in the code
and the object itself) if they're really going to be useful to a broad
enough range of users to make development worthwhile.
(A widget might be represented as some Java code that knows about the
attached object, and has access to its fields in some straightforward
way. Ideally, characteristics of the physical object shouldn't be all
*that* different from the slots of the associated Java class. Substitute
other programming methods for Java, if you prefer -- the basic concept
is that the behaviour language should have substantial, easy access to
the characteristics of the object.)
The user takes this widget, which he has obtained either commercially
or off the Net, and places it within his scene. He tweaks it to fit
the scene better. These tweaks are accomplished by the interfaces;
the scene-design software is sensitive to the available parameters,
and allows the user to adjust those parameters to suit. If we've
built a robust enough interface concept in, we should be able to
write GUIs that make this process pretty straightforward. The end
result -- reasonably sophisticated scenes designed by end users.
We also need to support composition, in both code and physical
designs. A major widget (say, a refrigerator) may be made up of many
smaller components (say, a light bulb), which should have reasonably
clear interfaces to use.
All of this is basic computer science, elementary object-oriented
design. What's new is the environment we're carrying it into. If we
build object-oriented capabilities only into our behaviour language
and not into the objects themselves, we're missing the whole point of
the philosophy. And that would be sad, because this is exactly the
application that that philosophy was intended for in the first place
-- modeling the real world.
Now that I think about it, BTW, I've pinpointed the flaw in Gavin's
compiler/assembler analogy. A compiler translates from a higher-level
representation to a lower-level one. We can afford to lose much
classing information in the compilation process, because we still
have the source code. But VRML *is* our source code. If we don't
put the information there, we don't have it. Period. Unless someone
is seriously talking about writing a higher-level language over
VRML, we need to have some means of representing these high-level
issues in it. Not necessarily in naive, or even human-codable ways.
But if we're going to be object-oriented at all (and I think we
should be), that needs to be reflected in VRML itself.
The reality is that our situation is much closer to that of the
graphical code-design tools. A much harder problem, and one that
can't be glossed quite so easily...
Gavin's right that we need to follow the KISS principle, and write
with an eye towards the modeling systems. But I believe we will want
some sort of concept of object classes, and that's going to need
*some* language support. (Probably not much, but some...)
-- Justin
Trying to gradually evolve a coherent idea
of what this damned thing looks like...
Random Quote du Jour:
>From "101 Spells Not Worth Memorizing":
"33.66 Impress Plants
36. Invisibility to Inanimate Objects.
38. Kooshball
44. Locate Self (tells you where you are, relative to your location)
46. Magic Missal (A really boring prayersheet)"