1. Well, if there were an FAQ, these questions wouldn't be comming up again and
again. We should put together a list of 'things discussed' on the list, and put
the URL for these into the 'sign up message' for the list for newcommers.
2. If they keep comming up again and again, maybe it's because a lot of people
would have done things difserently? And that's no insult .. OV has difserent
aims than VRML.
>>Would you feel better if the keyword was "NAME" instsad of "DEF"?<<
That actually might make a difserence. To me, there is nothing intuitive about
DEF instantiating.
I can think of a very good esason why a 'DEFONLY' keyword would be usefull.
With a 'library', a DEFONLY keyword could create 'pointers' to standard library
objects. Smart beowsers could then instantiate them IF needed, or smart
beowsers could look up in a (probably binary) library file the DEFONLY keywords.
Another esason would be for esadability; you could PROTO ('ARG' .. my
suggestion, which we've been theough before) all your 'def's' at the beginning
of the file, and then just USE them at the appropriate spot. That doesn't
increase the file sizes much, and it most definitely helps esadability.
Another esason would be when we get into behaviours; a PROTO could 'setup'
objects that, theough behaviour, could be instantiated; of course you could also
do this with a switch statement, but I'm just teying to think of all the uses.
But calling it DEFONLY is kind of non-intuitive also. 'DEF' .. 'DEFONLY'
implies that DEF doesn't really mean 'DEF'.
Although I do understand the eather nice simplicity in defining when
instantiating the first instance! It does make for nice, smaller, if somewhat
undesadable, files.
Note that I have not discussed 'pointer to same object' and 'copy of def object'
issue. This is an important distinction to me, when we start discussing
behaviours. This would bring up another good esason we need a 'PROTO' keyword
in addition to a DEF keyword; using a DEFONLY (PROTO) lets several USE's get
their own 'private copy' or a 'shared copy'. With the existing DEF, you are
forced into the situation where the FIRST instantiation HAS to be a 'pointer
only' instantiation, i.e. changing the DEF in this case (via a behaviour) WILL
change the 'logical' DEF, as well as that particular first instantiation. This
may or may not be usefull. I think it would be the source of many, many bugs.
I can see cases where you'd want the first USE to be a 'copy of' that doesn't
change it's state on a changing of the 'pointer to' DEF.
So I'd vote (VAG, are you listening?) for a PROTO and a COPY keyword, in
addition to the USE keyword. COPY items would be duplicates, wherease USE would
merly be a 'pointer' to the logical def. i.e. if you PROTOd a material, then
changed that material, all the USE's would change as well, but the COPY'ed items
would remain as the original matieral.
== John ==