On Tue, Aug 27, 2002 at 10:31:03AM +0200, Jean-Marc Lasgouttes wrote:
> Somehow I think that the factory should take the inset code as
> parameter, not the lfun.
Hm. Yes. I was thinking about these. But there are a few small and
subjective advantages for taking the lfun approach:
1. the lfun implicitly contains the inset code (we need the
switch mapping lfun->inset code anyway somewhere, this patch puts that in
the factory). So the lfun approach has at least the same potential.
2. right now the interface is minimal, for the code we'd need to include
insets/inset.h.
3. I believe the concept of inset codes is broken anyway. An member of a
inheritance hierarchy should identify itself by its behaviour, not by
returning some magic inset code and hope that the caller knows how to act.
[Constructing things is admittedly a bit different, but I still do not
believe that this rectifies the existance of inset codes]
4. Mathed uses a similar factory. To merge them into a single one some day
it's better not to rely on features that are present only in one of the
two existing inset hierarchies. Mathed does not have inset codes, but uses
lfuns, so the math factory could be changes to accept lfuns easily.
5. The lfun approach is actually more flexible. Right now calling
LFUN_MATH_MODE on a selection of "$a+b$" creates a InsetFormula whereas
callinf LFUN_MATH_MODE on a selection of "\def\foo{\bar}" creates a
InsetFormulaMacro. The goal of putting inset knowledge behind a
"firewall" would be missed if the corresponding logic needs to be done
before calling the factory.
6. The lfun approach can pass down additional parameters. Some of the
insets need bufferparams which could be derived from the lfun, but would
need an additional parameter when only inset codes are passed to the
factory.
> If the insets had an identifier (actually,
> they have one, which is written in the lyx file), we could have a
> simple lfun taking an argument
> insert-inset InsetFoot
This is possible with the lfun approach, too.
> 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.
No problem with that. Just that using lyxCode as function parameter does
not exactly sound like "getting rid of it" ;-)
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
