> All good reasons but make sure you give consideration to _why_ you
> need to identify insets. And then think long and hard about what
> happens when you add a new inset. How will that affect the code? If
> you find you are using dynamic_cast<> as a sort of switch statement or
> if..else if..else if.. structure then we need a better scheme.
Well, I think this scheme is the simplest imaginable. We do not require
any special things in the insets (called elements now ;-), and it works
with a class hierarchy.
> I'll again recommend trying to find a copy of "More Effective C++" by
> Scoot Meyers. He covers several schemes to mimimise the need for
> rtti. These mainly involve demonstrating how to view the problem from
> a different angle so that rtti is either no longer necessary or is
> more maintainable. I'm pretty sure its item 31.
If we assume that compilers can handle RTTI, I think this is the best
solution for the problem at hand. Scott Meyers deals with a different
situation where RTTI is not implemented efficiently. In that case, some
of his methods might make sense.
For LyX, I think we should stick with RTTI simply because it is the
simplest solution, provided that we solve the portability problem.
Greets,
Asger
P.S. Kernel 0.7 is not the most current one. We fixed some bugs in that
in the version that was introduced into the LyX development version. In
that process, we had to rename Inset to Element in order to avoid name
clashes, and thus, the Insets in the data structure are now called
Elements. That also makes the Inset term free for the more specific
concept similar to what we have in the 1.0.x branch.
