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. Ecerything else is just to make thins easier or localized in
another way.
| o several files are auto-generated with a perl script. This helps
| centralise the details of each lyxfunc
We we need autogeneration for that?
| o each lyxfunc has doxygen-style commentary (which is also interpreted to
| generate the automatic files)
|
| o lyxaction is gone, replaced with lf_container, which is a little more
| container-y, and contains no special code for handling the functions (it
| is basically a look-up facility)
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)
| o each lyxfunction handles itself, include pseudo-action functions
I didn't see how you handled pseudo actions.
Can you explain.
| o there's no extra expensive lookup for static functions on dispatch
??
| I would appreciate any comments anyone has got. Is this workable or am I
| crazy ? How do people feel about auto-generating files ?
I don't like the auto-generation.
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)
But: something like this is needed.
Lgb
