>>>>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Tue, Aug 27, 2002 at 10:31:03AM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> Somehow I think that the factory should take the inset code as
>> parameter, not the lfun.
Andre> Hm. Yes. I was thinking about these. But there are a few small
Andre> and subjective advantages for taking the lfun approach:
Andre> 1. the lfun implicitly contains the inset code (we need the
Andre> switch mapping lfun->inset code anyway somewhere, this patch
Andre> puts that in the factory). So the lfun approach has at least
Andre> the same potential.
OK.
Andre> 2. right now the interface is minimal, for the code we'd need
Andre> to include insets/inset.h.
OK.
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.
Andre> 5. The lfun approach is actually more flexible. Right now
Andre> calling LFUN_MATH_MODE on a selection of "$a+b$" creates a
Andre> InsetFormula whereas callinf LFUN_MATH_MODE on a selection of
Andre> "\def\foo{\bar}" creates a InsetFormulaMacro. The goal of
Andre> putting inset knowledge behind a "firewall" would be missed if
Andre> the corresponding logic needs to be done before calling the
Andre> factory.
OK.
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.
>> I think the way to go for insets is some autoregistration system
>> (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.
JMarc
