I see your point, but I think you could murder a few birds with one arrow if
you look at it as "Named Objects", where an Object can be a node, a set of
node or an entire (.wrl) file. Finding a soloution using this constraint
yields a much less specific soloution that can be used in many different
ways. That is (while I don't like the name for the keyword in the first
place) why I think DEF could still be overloaded a little more before its
use becomes clouded. In fact, if you think about it, it is not really even
"overloading" USE per se, but rather expanding its current semantic to be
more suited for generally object naming that can or cannot span files and
can or cannot load at point of definition. Granted, DEF is an ugly word, but
it is the one we have. I know you noticed (thank you) but this sort of
functionality has been important to me and something I've been pushing for
ever since I first cracked out of my egg and began chirping here.
As for your idea about it being a class, let me add my comments on that. I
usually think of a class as a compile time entity and an object as a runtime
one. As such, you can give a class various specifications that result in the
ability to have 3 different instantiations with three very different
personalities. Also, I think of a class as something that can be used to
create instances that are consistent with the other classes in a given
system. In the Example, IceCreamCone works much more like an Object (or even
more accurately an Aggregate Object made up of "using" relationships) or a
DEF that can have active reference to it in the form of USE. If IceCreamCone
were a class it would need the same sort of definable data slots or
behaviour that TransformSeparator (for example) has. In other words, after
defining IceCreamCone, you cannot instantiate it with varying parameters
such as radius, rototation, translation and so forth. I don't think I did a
very good job of providing a clear explaination, so if I have botched my
comments beyond cognition, let me know and I'll try again.
Anyway, in a very real sense what is being proposed *is* a way to create
variables for objects or node aggregations, which I prefer to think of as
object naming.
Robert