On Tue, Aug 27, 2002 at 05:43:23PM +0200, Jean-Marc Lasgouttes wrote: > Andre> 3. I believe the concept of inset codes is broken anyway. An > Andre> member of a inheritance hierarchy should identify itself by its > Andre> behaviour, not by returning some magic inset code and hope that > Andre> the caller knows how to act. [Constructing things is admittedly > Andre> a bit different, but I still do not believe that this rectifies > Andre> the existance of inset codes] > > We need them in some places, I think. Otherwise, we have to add dozens > of ad-hoc methods.
Maybe. The mathed aequivalent of "adhoc RTTI" aka "FooBarInset * MathInset::asFooBarInset" is not really nice either but has the advantage of being "inheritable"... (and if things are done were they belong there seems to be less need for such hacks. By the localization of the lfun handling in mathed I was able to remove two or three of them...) > Andre> 6. The lfun approach can pass down additional parameters. Some > Andre> of the insets need bufferparams which could be derived from the > Andre> lfun, but would need an additional parameter when only inset > Andre> codes are passed to the factory. > > One can always pass bufferparams. Not enough in all cases. Sometimes the BufferView would be needed (don't ask why, InsetFormula uses it - has been there from the beginning), some use a string argument (InsetTabular). So in the end we'd pass down virtually the same set that's currently wrapped up in a FuncRequest... > >> (should be easy) and identification by strings. Then we can get rid > >> of harcoded lyxCode and get a factory mostly for free. > > Andre> No problem with that. Just that using lyxCode as function > Andre> parameter does not exactly sound like "getting rid of it" ;-) > > What I mean is that insets would autoregister themselves with a char > const *, and that the pointer itself to this char const * could be > used as a replacement for lyxCode, as in > if inset->lyxCode() == InsetFoo::code > > This way, there would be no need for an hardcoded list of inset codes > in inset.h. And the autoregistration code would have a table of > existing insets, maybe with some entry points for creating a new inset > of this type. Ok. But certain insets would still need certain additional data be passed on creation, and for auto-registration we'd need a uniform constructor for all insets which takes that data.. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
