RE: [boost] Submission: typelist

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-11-28 19:21:21

> > Did you?  You said that you found mpl complex and you preferred
> > a simpler implementation, but I don't recall any reason why you
> > wouldn't want to *use* MPL if it were available.  Is there such
> > a big difference between writing loki::length and mpl::size that
> > the latter would be a problem?  It's shorter for one thing. :-)
> >
> > I'm sad to see this degenerate into a Loki vs MPL debate.
>
> Me too, that's a bummer. I had expected I'd go through trouble once I'll
> start submitting Loki to boost, but really I hadn't expected that much
> trouble and that early on :o).

I think this debate has gotten to the point of being non-productive.  Loki
should continue using its own typelists and Andrei should get on with it.  We
can worry about the "grand unified theory of typelists" when mpl is ready for
review.  Meanwhile, Mat Marcus has contributed code to allow Loki typelists to
work with VC6.  I'm sure there are plenty of boosters that need that for Loki to
be useful...

> As of using mpl in Loki, sure, that's not a big deal on the face of it.
> There are issues, though. So please allow me to state my viewpoint in
> submitting Loki to boost, viewpoint that I find reasonable. Again, I start
> from the assumption that the process is worthwhile and that Loki would add
> value to boost. Not everybody seems to think so; in case this is a general
> opinion around boost, I'd be glad to hear that, no hard feelings, so as not
> to waste everybody's time.

I believe Loki has several novel and useful components that Boost currently
lacks: singleton, factories, and multi-methods come to mind.  I also believe
Loki is could benefit from Boost techniques (online docs, better portability,
etc).  Since Andrei is starting to use Boost in the Loki implementation it seems
to me there is a strong motive to collaborate.  OTH, further down the line smart
pointers, functors, and threading all represent areas of significant overlap
between Loki and Boost.  I think these will be much harder to combine, so this
rocky start doesn't bode well.

> So again, here's my view:
>
> * If boost has a facility that does the same as a facility of Loki, and is
>   ...
>
> * If Loki has a facility that has a similar design as boost's but sports
>   ...
> * If Loki has a facility that I consider better that boost's, I will submit
>   Loki's facility. This is the case of mpl.

Your criteria seem reasonable to me.  I think you also have the right to
replicate exiting facilities if that makes it easier initially.

> In addition, I think it is not good to make gratuitous changes to Loki. It
> is well documented and has a growing user base. The names in loki ring bells
> to C++ programmers. So for example if we don't find a clearly better name
> for int2type and type2type I would suggest we keep them the same.

This, I think, is the most important point.  I would add my voice to several
others that have said that being able to point to detailed library documentation
is essential.  If you make too many changes then it will be difficult to map
from MC++D to the boost versions. There would be something to be said for
cutting thru all of this, slapping "namespace boost" around the Loki source,
working on getting it to compile on more platforms, and putting together html
docs as phase 1.  Then phase 2 could be to gradually combine / refactor Loki and
Boost libraries.

HTH,

Jeff