Re: [lmi] Delegating ctor uncalled for?

[Vadim Zeitlin]

On Sat, 4 Feb 2017 02:01:37 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-26 02:43, Greg Chicares wrote:
GC> [...]
GC> > As for me, I look at
GC> >   $grep 'TODO ??' input_seq* |wc -l
GC> > and see an opportunity to remove 26/422 = six percent of lmi's marked
GC> > defects.
...
GC> > Perhaps this class really wants delegating ctors: there's common
GC> > post-initialization in realize_vector().
GC> 
GC> Vadim, tell me if you disagree, but I don't think that's a good idea
GC> after all.

 I didn't comment on this part of the original 2017-01-26 email because I'm
quite intimidated by the InputSequence class and I don't really understand
what's going on with it, so I don't think my opinion here is worth much,
but:

GC> AIUI, delegation is most appropriate when there's one "complete" ctor
GC> that initializes everything--then simpler ctors can delegate to it
GC> (e.g., with some arguments defaulted) to make sure no initialization
GC> step is skipped.

 Yes, absolutely.

GC> In this case, however, the InputSequence ctors take disjoint sets of
GC> arguments. One takes only a single std::vector<double> argument with
GC> one value for each year, and turns it into an InputSequence: it just
GC> performs run-length encoding. Another takes numerous arguments that
GC> represent the full context used in the GUI, but that one includes no
GC> std::vector<double> argument. Therefore, any target ctor we might
GC> write for this class would be a new, least-complete ctor consisting
GC> only of this single line, which is the common initialization today:
GC>     realize_vector();
GC> and delegation would amount to nothing but elaborate syntactic sugar.

 If it could be useful to rewrite the "numerous arguments" ctor so that it
would generate a vector (or two?), i.e. if this would make it simpler, then
perhaps it could delegate to the other one, but in the current state I
indeed don't see much point in using delegation here.

 OTOH the current code still doesn't seem to be ideal to me because:

1. It definitely looks like it ought to be possible to reuse the code
   of the 3 ctors taking vectors in some way.
2. The "numerous arguments" ctor is IMO unwieldy and difficult to both
   use and read. I would strongly consider using named arguments idiom
   in order to avoid having a function with 9 parameters which is about
   twice greater than optimal.


 Last and really least: there are no [other] typos in this file, but this
line:

// but these pardigms are disjoint, so it could not easily accomodate

manages to misspell both "paradigms" and "accommodate", somehow. I hope
that by noticing this I will have been able to have contributed at least
something useful to this discussion.

 Regards,
VZ