Interesting, and a fairly good point. Not 100% pursuasive, though.
Consider -- the development environment is going to be a bit
different from Inventor's, in that objects are more likely to
be shared. (Yes, yes -- if you disagree with me on this point,
the argument *will* fall apart.)
This being the case, there is still some merit to parameterization.
Say I want to use the Ice Cream Cone that's over in library L, but I
want (say) the cone to be chocolate (ie, brown). Or I want the cone
(but not the lump of ice cream) to be stretched a bit. With the
simple model we have now, I have no choice but to copy the object, and
recolor the cone. If we had some concept of parameterization, on the
other hand, it might be possible to share the base "class" of ice
cream cones, while still retaining some valuable data sharing.
The basic point is well-taken, though. I still think there's a place
for classing and parameterization, but you're right that we need to
bear the development environment in mind -- people are *not* going to
be coding this stuff by hand.
So here's a point to ponder -- given that these scenes are going to
be developed with graphical tools, how *would* you implement concepts
like classing and exporting of interfaces? (Which is essentially what
I'm talking about here -- basic computer science questions, put into
an interesting context...)
-- Justin
Who has a few quick opinions, but wants
to think about this one a little...
Random Quote du Jour:
"There is an explanation for Attila. For Haman. For Cortez. For Cesare
Borgia. For Christie and Speck and Manson, and Nixon ... and Torquemada.
But only the Nemotropin know the explanation, and they smile as best they
can with bloody mandibles."
-- from "N is for Nemotropin"