lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Delegating ctor uncalled for?


From: Vadim Zeitlin
Subject: Re: [lmi] Delegating ctor uncalled for?
Date: Thu, 9 Feb 2017 17:45:24 +0100

On Thu, 9 Feb 2017 03:50:01 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-02-04 15:23, Vadim Zeitlin wrote:
...
GC> >  It's still simple enough to make a mistake with the order of these 5
GC> > arguments. Maybe I just make too many mistakes, but I really appreciate
GC> > APIs which prevent me from making them, so I'd strongly prefer to be able
GC> > to write
GC> > 
GC> >   InputSequence sequence
GC> >           (expression
GC> >           ,InputParameters()
GC> >                   .years_to_maturity(y2m)
GC> >                   .issue_age(ia)
GC> >                   .retirement_age(ra)
GC> >                   .inforce_duration(id)
GC> >                   .effective_year(ey)
GC> >           );
GC> 
GC> but introducing a dependency on yet another library to accomplish this
GC> is not so good

 I might write another reply with some less trivial comments later, but for
now I just wanted to clarify what looks like a misunderstanding to me: the
syntax above does _not_ require any third-party libraries and can, and
should, be implemented directly in InputParameters class itself, just as
it's done in e.g. wxFontInfo (which can be used to construct a wxFont
without checking the order of its parameters in the documentation).

 So while we could discuss whether this syntax is sufficiently preferable
to the current one or not ([TODO: use the time machine to insert references
to my less trivial comments in a future message here]), _if_ we agree that
it is indeed preferable, there is no need for any libraries to implement
it.

 Regards,
VZ


reply via email to

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