[Openvrml-develop] Header file consolidation

[Braden N. M. <br...@en...>]

OpenVRML has an irritatingly large number of headers for a number of
classes which are not at all likely to be used in isolation. This
complicates life for our users, who must use a number of #include
directives, and for us developers, who must frequently chase down a
different file when modifying OpenVRML.

The problem can be alleviated for users by adding Another Header which
does nothing but include a bunch of related headers. We used to do this,
in fact, but I kicked it to the curb after finding that it was rather
difficult to keep up-to-date in a library evolving as OpenVRML is. So I
am not fond of this option.

Another option is to consolidate public classes into fewer headers. In
general, a rule of "1 header file and 1 implementation file per class"
has been followed in OpenVRML. This is a simple and
frequently-encountered convention for C++ projects, but I do not think
it suits nontrivial C++ library projects particularly well. For header
files, there is the problem of presenting lots of header files to users.
For implementation files, there is the problem that often
implementations ought to share private (internally linked)
implementation details. In fact, this is presently demonstrated in
VrmlField.cpp, where the "rule" in place has been bent to accommodate
the need for many of the MF* types to share implementation details. Such
a requirement is not particularly exceptional, and it should not be
treated as such.

So in spite of the subject heading, I'm actually proposing that both
headers and implementations be consolidated. The field types are the
most obvious consolidation, largely because it's already partly done;
the headers simply need to be consolidated here. I'd like to take this
further, though. I think the VRML97 node classes could be consolidated.
Some of the core functionality could probably be consolidated as well,
though the optimal partitions aren't entirely clear to me yet.

Braden