[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
Re: [lmi] Delegating ctor uncalled for?, Greg Chicares, 2017/02/06
Re: [lmi] Delegating ctor uncalled for?, Greg Chicares, 2017/02/08