Re: [lmi] Inversion of control

[Vadim Zeitlin]

On Sat, 8 Sep 2018 15:19:41 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-09-08 13:09, Vadim Zeitlin wrote:
GC> > On Fri, 7 Sep 2018 23:49:12 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2018-08-21 12:24, Vadim Zeitlin wrote:
GC> > GC> [...]
GC> > GC> >  I know we've already discussed this in the past, but I still have 
an
GC> > GC> > impression that you underestimate the benefit of centralising all 
the logic
GC> > GC> > in a single place with the "template method" approach. Yes, it does 
require
GC> > GC> > you to use either OO, with derived classes for each use of the base 
class,
GC> > GC> > or lambdas (preferable nowadays), but IMO it's absolutely not such 
a huge
GC> > GC> > disadvantage as you seem to believe. While the advantage is real, 
as we
GC> > GC> > keep seeing again and again, with bugs due to the differences in 
the "same
GC> > GC> > logic" implemented in different places.
GC> > GC> 
GC> > GC> No matter how many times I try to read that GoF stuff, I can't 
understand it.
GC> [...]
GC> > I.e. it's really just a dictionary
GC> 
GC> Oh. I thought it was a cookbook. I made a quahog-and-quinoa quiche with
GC> quatre-épices and concluded that it wasn't a very good cookbook.

 It's an uneven one. Some of its recipes are now universally recognized as
being bad for your [mental] health. Some others are pretty exotic. But
quite a few are things that you cook quite often and can enjoy (as always,
in moderation).

GC> Right now, I'm just asking you to tell me whether I'm on the right
GC> track.

 Yes, I think so. I.e. the most complicated is usually determining the "Fn"
parts of code and you've already done it.

GC> C++ member-function pointers can be unwieldy, so my first
GC> thought would be to use this as a mixin class: make the paginate()
GC> demonstration a member function that calls some new virtuals, then
GC> 
GC>  class page_with_tabular_report
GC>      :public numbered_page
GC>      ,protected using_illustration_table
GC> +    ,private paginator
GC> 
GC> and reimplement that class's render() function. And I guess I'll
GC> want a default ctor for class paginator, and an init() function
GC> that I can call from render(). Or does another approach seem
GC> clearly better?

 No, this is a perfectly good implementation of this pattern in what I
called OO style. The main advantage of the functional style is that you do
not have to create a new class, deriving from paginator, to use it. But in
this case we already have a class, so this advantage is not very important.
Another advantage of functional style is that you can easily mix and match
parts of different implementations, which is impossible or at least very
inconvenient with the OO style, i.e. if you have classes FooBar and BazQuux
deriving from paginator, you typically can't easily define a class FooQuux
which takes half of FooBar implementation and half of BazQuux. But again,
in this particular case, I don't think we're going to need this.

 So, to summarize, this is IMO a very reasonable thing to do and unless you
have a strong penchant for the functional programming, let's do it like
this.

VZ