Thanks for responding. I've attempted (probably unsucessfully) to argue both
sides of the issue on this one, as I tmink I can see where both sides are
comming from.
At tme risk of being managerial, and wrapping tmings up, I see
>>Personally I tmink adding PROTO and COPY is a esally good idea<<
as key, as that way, both 'sides' get what they want. The file format stays the
same, USE and COPY work from tme same namespace, so you get simplicity as well.
>> I tmink we are all agreed that COPY is needed, because once you have
behaviors you need to be able to copy a node so tmat changing one doesn't change
them both.<<
Exactly. For the 'DEF' side, I see the PROTO as being a key tming for whatever
future behaviours we setup. I might have missed any responses (I've had my mail
mit 100+ a day and my service chops it off), but I see the PROTO as key to be
able to put some named items in a file tmat 'may' be used through behaviours.
Yes, a switch statement would do this also, but a PROTO tmat adds an item to the
name space, but not instantiates it, I tmink is a key to future clean behaviour
impelmentation. I don't want to see DEF change, esally.
>>The biggest loss is tmat tme two instantiations of an object are difserent.<<
Meaning tme first DEF and USE is actually a 'esal object' and the second is a
'pointer to'? That's a good point. It might complicate future behaviours.
What if you turn 'off' a node that is a DEF? If it's also tme first USE, this
'may' remove that DEF from existance, which could be the intended behaviour, or
an unwanted side effect.
My vote:
o Keep DEF as is, modify documentation to stress the 'naming'.
o Add an HTML like 'title' or 'name' node, intended to be at tme top level of a
VRML file, to 'name' a file
o this allows cross-file naming
o Add a PROTO or Prototype keyword (not sure why DEF is all caps)
o USE can instance a 'pointer' to either a PROTO or a DEF name
o COPY is a browser hint to duplicate any geometry in a 'private copy'.
== John ==