> > the command?
> >
> > Comparing strings instead numbers should cost only a constant factor of
> > time more than comparing enums, starting off from a very tiny amount.
> > Morover, lookup in the map is O(ln n) compared to O(n) in the
> > big case scwitch. So it shold not really be noticable.
>
> you are forgetting the constants of the complexity equation.
No. I am not. First of all I mentiond the existence of a constant factor
and second, it does not matter. Even if the factor was 1000.
How many lyx-functions are called per second? 1000? Likely less.
Now, how long take 1000 string lookups in a map with 100 entries?
Relate this to the work done by a complete table-redraw.
Got it? ;-)
> And I don't see any real purpose to removing the array-based approach ?
Code decoupling. LyX still takes ages to compile even after tiny changes.
> would we really ever want to do this ?
Why not? Most larger apps come with dynamically lodable modules.
I don't see any reason e.g. to carry all SGML stuff in a monolithic binary
if I don't need it most of the time.
> I don't see a good reason to lose
> compile-time type safety, and this doesn't really help at all in terms of
> readability of each function.
Could you explain that? The function tags will go away entirely.
The commands are pretty invisible to "user code".
> Think about how we would add the author's
> name and creation date, detailed usage instructions for the developer etc.
The creation date of the lyxfunc? You lost me.
Andre'
--
André Pönitz ........................................ [EMAIL PROTECTED]
