Boost logo

Boost :

Subject: Re: [boost] [GSoC, MPL11] Community probe
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-04-22 15:55:20


On 4/22/2014 10:09 AM, Louis Dionne wrote:
> Dear Boost,
>
> As a follow-up to [1], I am probing the community to help clarify what
> are your needs/expectations with respect to a new TMP library. Your
> involvement is important as it will help direct my work on an eventual
> successor to the MPL (in consultation with my mentor, Joel Falcou).
>
> I expect this to be the first of a series of probes to the community. This
> one focuses on backward compatibility with the MPL.
>
> COMMUNITY PROBE
> ---------------
> Please comment on how you would like to see the following points addressed
> by a new TMP library:
>
> (1) Backward compatibility with the MPL. Should it be a swap-in
> replacement? Is it enough to have an easy way to interoperate
> between both libraries (think Fusion/MPL interoperation)?.

I do not think you must strive for perfect backward compatibility. But
if you can provide an easy interoperation in as many places as possible
that would be helpful. In particular, however, do not change a better
design, when you have one, just to provide a means of backward
compatibility.

>
> (2) Learning curve for users coming from the MPL. How important is it
> for you to be able to reuse your knowledge of the MPL (not of TMP,
> but of the MPL itself)?.

If one understands the MPL ( no easy initial task ) it should be fairly
easy to understand whatever your library's different idioms might be. So
I do not think you should worry about the learning curve but rather just
document your library as thoroughly as possible. At the level of the
MPL, and template metaprogramming in general, a C++ programmer has to be
good enough technically that he will understand your library if it is
documented well. Whatever is not understood will be asked about when
your library is reviewed, and that feedback will enable you to improve
any documentation which may be found wanting.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk