On 15 Jan 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | o no longer is the various parts of a new function spread in four or five
> | different places. To add a new function means adding it to functions.C,
> | and (if necessary) a status tester to status_functions.C
>
> but that is almost true today as well. To add a new lyxfund you add to
> the enum in commandtags.h, add an item in LyXAction.C and a case in
> LyXFunc.
exactly ! It is *much* nicer to have it all in exactly one place IMHO
> Ecerything else is just to make thins easier or localized in
> another way.
could you expand ?
> | o several files are auto-generated with a perl script. This helps
> | centralise the details of each lyxfunc
>
> We we need autogeneration for that?
at the very least, without auto generation, you need :
1 place for the commandtag (commandtags.h)
1 place for the invoke method (lyxfunc.C)
1 place for the instantiation of the lyxfunc (LyXAction.C)
I don't see how these can be centralised into a single file (+ header
file) w/o auto-gen
> Couln't much of what you do be done with added some more fields to the
> LyXAction lfun_item?
> (In your case a function pointer)
sure, if you think lfun_item items[] is readable (I don't). And also this
requires me to manually split up the Dispatch() switch, and then add the
various bits in the right place in items[]. No thanks ...
> I didn't see how you handled pseudo actions.
> Can you explain.
This is the vague part (I only spent a short while messing with this). I
think what happens is that the code creating the pseudo-action
(i.e. similar to existing getPseudoAction()) will ask the lf_container
addAction(), which will instantiate a newly create lyxfunction object. The
lyxfunction is generated and the real action + its argument is stored
inside that lyxfunction (see second lyxfunction c-tor).
At invoke time, the operator() will pick up the real action + argument,
and invoke that instead.
Access to the pseudo action is vi lf_container maps.
> | o there's no extra expensive lookup for static functions on dispatch
>
> ??
... I mean as in the old code. e.g. LFUN_RIGHT dispatch is just an array
offset rather than some map lookup or something. This needs to be as fast
as possible, right ?
> Also I feel you use pointer too much, but that should be a detail.
> (you also pass objects by value, should be passed by const reference)
yes, all the C++ good practice stuff should be shaken out if the code gets
worked out
thanks
john
--
"Threads are for people who can't program state machines."
- Alan Cox
