Re: [lmi] Preliminary emit_ledger code refactoring

[Greg Chicares]

On 2015-08-04 16:28, Vadim Zeitlin wrote:
[...]
>  The important question now is whether you plan any more changes to this
> code or if this is its final form and if I should already rebase my
> existing patches on your changes? This is not going to be trivial as the
> code in svn is now completely different from both the original version and
> the one I have, so I'm going to have to resolve conflicts for all my
> changes. It's not the end of the world (with git, with svn I'd have
> already started crying my eyes out), but I'd prefer to do it only once if
> possible, so if you plan more changes in this area I'd rather wait for
> them.

I don't want to inconvenience you. Tell you what. Don't merge my changes
yet. Just finish (once specifications stabilize) the work you're doing
elsewhere to generate PDF files, and hand it to me with the class derived
from ledger_emitter_single_output_base that you would have added to
'emit_ledger.cpp'...and I'll glue it all together.

>  In particular I wonder about
> 
>       /// Each member function (except the lightweight ctor and dtor)
>       /// returns time spent, which is almost always wanted.
> 
> comment. Does it really mean that you are not going to apply the patch
> refactoring the timers neither? For me this one seemed to be even more
> obviously the right thing to do as the existing code could be used as a
> nice example of why separation of concerns is a good thing to have, so I'd
> be rather surprised if you didn't agree with it. But then, of course, I'm
> already surprised, so this is not a good argument neither...

Here I guess we'll have to agree to disagree. Suppose I have a function
  void calculate();
(that does exactly one job), and I always want that calculation to be
instrumented...so I write

  double calculate_with_instrumentation()
    {
    start-timer
    call calculate() [which becomes non-public]
    stop-timer
    return timing
    }

and use that instead of calculate() everywhere.

Pros:
  less code to write everywhere the function is called
  can't forget to write instrumentation for each call
  unifies two concerns that are intimately linked
Cons:
  combines two concerns that might conceivably be separated

For me, the "Pros" win, hands down.