Re: [GSoC] On "ODF Formulas in Writer"

So, although this will not be a GSOC task, I'd like to answer some of
the questions for archival purposes.

On Tue, 2014-03-11 at 12:53 +0100, Michael Stahl wrote:

> that is the part of the idea proposal that i'm not sure about currently:
>
> just using this "ixion" library for Writer formulas would put us in a
> similar situation like what we currently are with text edition
> components, where Writer has its own core and everything else uses
> EditEngine instead; this duplication creates additional maintenance burden.
>
> of course there are a lot of formulas (ODF part 2 is hundreds of pages),
> and to me it appears quite sub-optimal to have multiple implementations
> of all that.
>
> there is already a "formula" module which Eike claims is not just used
> by Calc but also by some Report(Builder/Designer/whatever) application,
> which means it would probably be possible to use this from Writer too.
>
> the problem is that apparently "formula" only contains the code to parse
> and tokenize formulas; the actual evaluation is still in Calc's core and
> tied to Calc's internals.
>
> so i would welcome some input on what the architecture should look like
> here:
>
> 1) is it possible to somehow abstract the formula evaluation
>    implementations from Calc internals (suppose it's mostly about
>    addressing/accessing the cells?) such that it could be used from
>    Writer too?

Possible?  Yes, in the sense that anything is possible given enough
time.  But IMO probably not realistic and perhaps its risk outweighs its
potential benefit.  Calc's current formula interpreter code is so tied
to Calc's own internal model not just from functionality point of view
but also performance optimization point of view.  Ripping that out and
abstracting it for other apps to use would probably be not worth the
disruption it would bring.  Even the current sc/formula split just to
make the parser part of the formula engine available for other parts of
the code base has made the handling of formula engine a bit more awkward
inside Calc, to say the least.

> 2) would it be a good long-term plan to migrate Calc to ixion too so we
>    eventually end up with just one formula evaluation engine?

This was the initial thinking behind the inception of ixion.  But 4
years has passed, and the likelihood of ixion replacing Calc's formula
engine has diminished.  The possibility is still there, but let's say
that won't be happening in the next 5 years.

> 3) or is it unrealistic to ever share the formula evaluation part?

I'd say yes.  It's unrealistic.

So, if I were to implement this feature, I would still consider using
ixion despite the downside of duplication you've already cited.  The
reality is that we do have to duplicate functionality sometimes for many
reasons even though we all know that it's something to be frowned upon.
At least with ixion you'll get formula parser, interpreter, A1 style
cell address handler and lightweight dependency tracking "for free"
right now.  And although I don't think ixion is ready for heavy-lifting
formula calculation uses, it should work well enough for light-weight
uses such as Writer table's formula handling.

Anyway, since we won't be working on this feature anytime soon, we can
shelve this discussion for now, I suppose.

Kohei