[openvrml-develop] Rearchitecture issue

[Braden M. <br...@ln...>]

I've hit a bit of a wall on the rearchitecture branch, and I'm hoping to
get some opinions before deciding whether to climb over it or knock it
down.

Background
----------
Script nodes are unique in that interfaces get added to them at the
instantiation point. This has important implications for a type
information object for nodes. Whereas most nodes can share a single type
information object among all nodes of a given type, each Script node
instance must have its own type information object instance.

Problem
-------
I've gone to significant effort in the rearchitecture to make Script
nodes behave just like any other node type in all but a few
circumstances. ScriptNode inherits Node, which has a reference to the
NodeType object. While for most nodes the NodeType reference is
initialized with a pre-existing NodeType object, the NodeType for Script
nodes is part of the ScriptNode instance--so it doesn't get initialized
until the ScriptNode is initialized.

The implication of this is that when constructing a ScriptNode, while
ScriptNode's base class Node is being constructed, the reference to the
NodeType isn't valid yet.

This presents a problem for the call to setBVolumeDirty in Node's
constructor. setBVolumeDirty accesses the VrmlScene (through the invalid
NodeType), causing a segfault.

Potential solutions
-------------------
There are three potential solutions I see:
        1. Without dramatically changing the design, figure out how to
           initialize the ScriptNode's NodeType before the Node
           constructor gets called.
        2. Make a signficant design change.
        3. Make a rule, "Don't access the NodeType from the constructor
           for Node (or ChildNode)."

1 is the ideal solution. I'm not convinced it's possible, though. The
only possible contortion of the code I've been able to come up with
doesn't work in gcc 3.0.4, and is probably of questionable
well-formedness with respect to the C++ standard.

2 is least desirable for obvious reasons, but of course it's what needs
to happen if we can't come up with a viable alternative.

If 1 is indeed intractable, 3 starts to look very attractive. But is it
realistic? Node::setBVolumeDirty sets a flag on VrmlScene,
d_flags_need_updating. But as far as I can tell, this flag never gets
checked. cks, I think this is something you added. Can you tell me more
about it?

Braden