Re: [lmi] Cover-page simplification

[Vadim Zeitlin]

On Wed, 15 May 2019 00:33:47 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-04-24 17:47, Vadim Zeitlin wrote:
GC> > On Tue, 23 Apr 2019 16:29:15 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2018-11-28 17:45, Greg Chicares wrote:
GC> > GC> >  (D) ultimately: cover page = 1 of N, 2 of N, ... N-1 of N, N of N
GC> > GC> >    where N = page count =
GC> > GC> >            1 numbered cover page
GC> > GC> >        + N-1 other numbered non-duplicate pages
GC> > GC> >        +   0 i.e., zero duplicate signature pages
GC> > GC> 
GC> > GC> The full original posting is here:
GC> > GC>   https://lists.nongnu.org/archive/html/lmi/2018-11/msg00045.html
GC> > GC> 
GC> > GC> We want to implement (D) now--but to exclude the 'mce_finra' ledger 
type
GC> > GC> because it would require a regulatory filing.
GC> 
GC> 'mce_finra' is still treated the old way for now, but today we've
GC> achieved (D) above for two of the other three ledger types (and
GC> the fourth already had the (D) behavior).

 Thanks for doing this and, FWIW, I did look over the changes in the email
notifications and don't have any comments about it.

GC> > GC> Or would it be better to refactor this as
GC> > GC> 
GC> > GC>   class A {
GC> > GC>     protected: virtual void do_foo(); // overridable part
GC> > GC>     public: void foo() // not virtual
GC> > GC>       {
GC> > GC>       // code that must be done first
GC> > GC>       do_foo(); // call virtual
GC> > GC>       // code that must be done last
GC> > GC>       }
GC> > GC> 
GC> > GC> ?
GC> > 
GC> >  Yes, I think it would (FWIW this is called "template method" pattern,
GC> > which is confusing to C++ programmers because it has nothing to do with 
C++
GC> > templates, but you have to remember that the word "template" does also 
have
GC> > a meaning in languages other than C++, such as English). I'm too lazy to
GC> > hunt for the exact reference in the archives, but I'm pretty sure that 
I've
GC> > proposed something like this a couple of times in the past but you found
GC> > that it introduced unnecessary complexity (I do agree that this version is
GC> > more complex, I just think that in many cases its advantages outweigh the
GC> > extra complexity), so I've been trying to avoid using it unless the
GC> > alternative was really unpalatable.
GC> 
GC> That's what "template method" is supposed to mean?

 Yes, it just designates a way to let the derived class override some part
of an algorithm defined by the base class. As I said, the name is very
confusing in the context of C++ because "template" here means just that the
base class defines the "shape" (== "template") of the algorithm which is
then "filled in" by the derived class. This is completely unrelated to
templates in C++ sense, it's just that the word "template" has multiple
meanings and (I'll resist the temptation to use the word "overloaded" here
to avoid confusing matters even more).

GC> However, perfect generality, if even achievable, is costly. It's hard or
GC> impossible to know in advance which virtuals will need to be elaborated
GC> this way.

 Yes, sure, but as long as all the code using this approach is under our
control, it's pretty flexible and easy to update as the compiler will
helpfully point out anything that hasn't been changed, so in practice
guessing not quite right initially is not catastrophic. Things are rather
different when you use this pattern in a library and have to worry about
backwards compatibility when changing it later but, luckily, this is not
a concern here.


GC> > GC> Should cover_page derive from standard_page rather than numbered_page,
GC> > GC> in the hope that numbered_page::get_extra_pages_needed() will DTRT for
GC> > GC> the cover page?
GC> > 
GC> >  get_extra_pages_needed() definitely should DTRT, but the problem is that
GC> > we can't define the cover page contents using just the HTML template,
GC> > precisely because of the rectangle mentioned below. So as long as we keep
GC> > this rectangle, we can't derive cover_page from standard_page.
GC> 
GC> Now, we can, because we've removed that rectangle.

 This looks a bit like cheating, but if nobody objects to its removal, this
is definitely the simplest solution.

GC> > GC> Is there any reasonable way to make the big rectangle on the cover 
page
GC> > GC> adapt to the height of any footers we might add there? (If that's not
GC> > GC> easy, then we might ask whether that rectangle is truly worthwhile.)
GC> > 
GC> >  The rectangle on its own is not a problem, as it's just drawn around the
GC> > cover page contents. The problem is the ugly hack in cover.mst adding just
GC> > enough of <br> tags to make the cover page contents fill up the page area.
GC> 
GC> Today I was very glad that you'd mentioned that, because with the
GC> changes committed a few hours ago I had to remove some of those
GC> <br> elements.

 This problem still remains, however, rectangle or not... Unfortunately I
still haven't had any breakthrough and can't propose any good solution for
handling this.

 Regards,
VZ