John Levon <[EMAIL PROTECTED]> writes:
| 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
mmm, and I am not sure that I agree completely... I had one thing
planned: get rid of LFUN and the commandtags, and just use strings instead.
I also planned on adding a register method to LyXAction or LyXFunc to
that lyxfunc could register themselves.
(this would also open up for dynamic creations fo lyxfunc through
script language or dynamic loaded functions)
namespace LFUN {
bool insert_string(lyxfunc & lf) {
// do the stuff
}
}
lyxfunc.register("insert-string", LFUN::insert_string, NEEDS_BUFFER);
lyxfunc.register_pseudo("insert-666", "insert-string", "666");
lyxfunc.dispatch("insert-666");
| 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)
we can probalby drop the command tags.
| 1 place for the invoke method (lyxfunc.C)
this can be generic and needs to be written only once.
| 1 place for the instantiation of the lyxfunc (LyXAction.C)
multiple places... if wanted or all in the same location.
| I don't see how these can be centralised into a single file (+ header
| file) w/o auto-gen
I think it is doable.
| > 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 ...
Note that lfun_item items[] is the way it is to speed up
initialization.
| > 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).
Yes. A wrapper around he real func + arg.
|
| > | 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 ?
Well in a way yes, but _speed_ should /not/ be our main concern, clear
and easy to follow code should.
| > 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
You really should go to the boost site (www.boost.org) and see if you
can find anything usefull there.
Lgb
