Thorsten Froehlich wrote:
> Warp wrote:
>> Thorsten Froehlich <tho### [at] trfde> wrote:
>>> But those are in the parser and not used for dynamic binding!?!
>>   They are not doing dynamic binding because they are written in C.
>> However, the functionality they are performing is something quite
>> typical of what dynamic binding is for. In typical OO code you don't
>> write such gigantic switch-case blocks but instead you inherit from
>> a base class which has the proper virtual functions to do the same
>> task.
> 
> I think we are talking about two different things here.

To elaborate some more:

I do guess that your view is of the SDL as just that, a static description
(in the layer above preprocessing via macros and so on) of objects that is
read from a file and replicated in memory. While this perspective my appear
correct at first, second and third sight, it does not actually represent the
nature of a scene description.

Pressing a SDL (I did this at work for VRML 97 a few years ago, so I cannot
share the code that would illustrate it) in a completely get/set driven
manner, with object descriptions created by binding the get/set methods as
parser rules, may be appealing. Unfortunately, implementing even with the
most advanced template structures to support it, is not all that easy. Apart
from the approximately two abstraction layers in form of intermediate
template functions (which cost nothing, but *are* visible when debugging),
to define an object almost always involves some terminal rules to be
executed that depend on other information. In essence, you gain
interdependencies of data on previously parsed data, or (more difficult)
data that is still to be parsed or may be entirely optional.

Dealing with these cases is certainly possible, but you end up with more
than just get/set rules. Instead, you end up with rules as object creation
to set default values, rules for setting a parsed data, rules for
post-processing results after parsing everything else, and rules for setting
data after that. All those do share a lot of dependencies. Factoring each
into separate methods is possible. Factoring each special handling case into
methods is possible as well. However, suddenly what would have been 10 case
statements and some leading and trailing code has turned into 10 methods,
each calling two or three other methods that contain the shared code.

Each such method contains only a handful of lines of code. And conventional
wisdom holds that small methods are easy to maintain, but if you have a
swarm of 10 methods, depending on about 20 shared methods, all working on
the same object, you suddenly have decomposed sequential conditional code
into a complex tree of method calls. The code will be easy to read for sure,
*but* it will no longer be as easily understood.

Does this mean the get/set pattern does not work for an SDL? No, absolutely
not. It just means that a case-switch pattern will still be very useful: The
parser needs to be abstracted such that all possible values are sequential
starting at zero, and then you get a very efficient switch-case statement.
Even better, you also retain easy to maintain code that others can
understand quickly. Call it a tradeoff between maintainability and elegance
if you want to, it certainly is, but it also is a rather pragmatic approach
and has no performance drawbacks whatsoever. It may not be the most elegant,
but it will certainly be fast and easy to maintain. In the end, that is what
counts the most...

	Thorsten

Post a reply to this message