John Levon <[EMAIL PROTECTED]> writes:
| OK, in fact I think we agree on almost everything. Let me try and
| summarise a little :
:-)
| 1) everyone agrees that each lyxfunction should look after itself. This
| includes pseudo-actions, which should be able to invoke their real
| action *themselves*
I am not quite sure what you mean with "should look after itself".
| 2) everyone agrees there is a need for some object to contain every
| lyxfunction, and provide various methods of looking it up
Yes, a std::map would be my choice.
| 3) Lars and Andre argue for a string-based lookup. This shouldn't cause
| any performance problems, and has the advantage of making
| dynamically-added lyxfunctions easier. I agree, after consideration, that
| string-based lookup as the primary method is good
jupp
| 4) There needs to be some way to deal with the frontend menus. These are
| integer-based. There are only two options here :
|
| i) each frontend has a container mapping from integer values to
| strings, used on dispatch
|
| ii) each lyxfunctions is assigned an integer ID, and the ability
| to lookup in the container by ID is added.
|
| Lars must be suggesting option i).
No, nor really. Closer to ii).
The problem with ii) as I read it is O(n), and we can easily make this
O(1) by having a second container with pointer (iterators) into the
real functionmap. This alos means that the func number is not stored
explicitly anywere.
[some snip]
| 5) Lars doesn't like the idea of generated code. John does ;) because
|
| a) centralisation of all aspects of a lyxfunction. Lars previously
| stated this wasn't of much concern to him, but I *definitely* agree
| with JMarc that jumping all over the place when debugging is a pain
| (along with hoping to increase my understanding of the lyx code,
| this is my major motivation of the re-working).
oh, I agree with both you and JM on this.
| b) the array in LyXAction.C does not give scope for adding
| documentation, in an easy and readable way. The separation of the
| method code (currently in the LyXFunc.C switch) from the lyxfunction
| properties is a BAD thing.
the LyXAction aray will go, regardsless of the, but will perhaps be
replaced by a new array :-)
| c) Reference.lyx. 'Nuff said.
agree
| d) doxygen output. Oh I would like a developer's description of what
| each LyXFunction does. Keeping it in the new functions.C would be
| very nice
but this has certainly nothing to do with autogeneration of files.
| e) some other things I've forgotten
I think the only issue now is how to register LFUNs in LyXFunc.
| Comments ?
You, got them.
Lgb
