RE: [boost] Submission: typelist

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-11-29 12:53:22

Beman Dawes wrote:
>
> While I have sympathy for trying to preserve names and other features of
> existing libraries when there are no clearly better alternatives, in
> general we don't want to give up our "peer-review" responsibilities.
>
> The concept of "peer-review" is central to Boost.  We aren't living up to
> our ideals if we just rubber stamp a library when Boost members have
> serious reservations about it.

I wasn't suggesting that we give up on peer-review.  It just seemed that the
discussion around mpl versus loki typelists and various naming has bogged down
without clear advantages on either side.  Given that mpl hasn't been reviewed
yet it just seems a shame to delay Andrei's work on this point which I believe
can be decided after both libraries mature further.

> If it is an issue of implementation internals, then the "detail" namespace
> and similar mechanisms can be used by a library author to shield techniques
> which otherwise are problematic.  But for public interfaces, we really want
> to tread carefully when there is serious disagreement.  We don't always
> have to convince everyone that one particular way is best, but we would
> like to reach a point where all the technical issues are well understood,
> and there is a clear statement of the pros and cons of each approach.

Absolutely agreed.  So let me try to summarize:

At the end of the day, I think that the typelist issue is mostly an
implementation issue unless the Boost version of Loki would move away from a
macro interface for typelists.  For a random example, as a Loki library user I
want to do something like (see MC++D p226)

typedef MyConcreteFactory
<
  SomeAbstractFactory,
  CreationPolicy,
  TYPELIST_3(Type1, Type2, Type3)
>
MyFactory;

If TYPELIST_3 uses Loki typelists or mpl under the hood is not important to the
user unless one has some demonstrable portability or other implementation
advantage.  As long as the interface will be TYPELIST_3 then the implementation
can be changed later.  I guess I haven't seen a compelling argument that there
is a template-based solution for this interface.

Here's how I see the second issue: naming of int2type, type2type. First off,  I
believe is a pure implementation issue although some might want this device for
other libraries:

Pros to using different names for int2type, type2type:
 - Perhaps a clearer name (not much consensus on the list here)
Cons
 - invalidates MC++D documentation
 - Substantial changes to Loki required to merge with Boost

To me this clearly says stick with the current names.

Jeff