On Wed, Apr 05, 2006 at 03:58:11PM +0000, Angus Leeming wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > >> I thought André and Lars both complained that you > >> were subverting C++'s built in polymorphicism with > >> your own homemade version and that you should use > >> separate classes for each frac type, all living in > >> mathfrac.[Ch] or whatever it's called. > > > Was it a complaint? I don't remember it that way. > > You obviously have a thick skin ;-)
Ah no, I'm just 'semantically obtuse'. My wife complains about that too -- you have to actually _say_ things to me to make me understand them ;-) > Lars> Can we use something a bit stronger typed > Lars> for the kind parameter? Done -- an enum. > Martin> Looking at tfrac and dfrac, I would rather > Martin> merge them with frac too, as they are so small > Martin> that separate insets is overkill. IMHO. > > André> The only overkill is having lots of small > André> files turning into 200k monsters in a debug > André> compile. [I personally wouldn't mind having > André> all frac-like insets in a single (pair of) > André> file(s). But that does match the rest of LyX.] I think Andre means "does NOT match" > André> Apart from that the 'multiple insets' solution > André> is cleaner and faster at run time. No 'if' etc. > > André> Your 'combined' version is basically > André> hand-crafted 'polymorphy' on top of > André> the already existing inset hierarchy. It remains a matter of taste. Should we also split out \frac and \atop? More important than runtime here is legibility / maintainability of the source. Splitting out classes with only trivial differences between them leads to swarms of diminutive .[Ch] file pairs mostly repeating each other -- not good. No, I won't carry out my threat of merging in also \dfrac and \tfrac. Leaving good enough alone ;-) - Martin
pgpx645bVeZrW.pgp
Description: PGP signature
