[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Preliminary emit_ledger code refactoring

From: Greg Chicares
Subject: Re: [lmi] Preliminary emit_ledger code refactoring
Date: Tue, 04 Aug 2015 19:23:59 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

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()
    call calculate() [which becomes non-public]
    return timing

and use that instead of calculate() everywhere.

  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
  combines two concerns that might conceivably be separated

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]