[boost] Adding Loki to Boost (reprise)

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-09 20:16:39

Hi everyone,

It's the beginning of the quarter so I got some time to write a post that
I've been thinking about for a while. This post is going to be mildly long,
and it contains some considerations that I've been ruminating on for quite a
while. Also, this post has more "I"s and "me"s than would be preferrable,
because it describes the views and the opinions of yours truly. Accept my
apologies in advance for that.

In short, after the first failed attempt, I would like to propose aggain
adding loki to boost, but this time with a very different attitude: I want
to ask boost community's help in doing that. Explanations follow.

In making the first integration attempt, I situated myself from the
beginning on a position of negotiation. Ideally, I was thinking, loki would
be integrated in boost with minimal change, obtainable through a mechanic
translation (awk scripts). This way, I was thinking, there are two important
advantages:

(1) There is only one point of maintenance for loki proper and for loki as
integrated in boost

(2) The "conceptual integrity" that Fred Brooks tells about in "The Mythical
Man-Month" will be preserved. One thing I wanted to avoid was to have loki
redesigned by a committee of people who are well intended, but have very
different views and opinions on what's good - and in particular, opinions
different from my own.

What happened next is history. Situating myself on a position of power and
negotiation was naturally an annoyance to everybody else. I was perceived as
snooty and crotchety, and while this was not my intention, it is undoubtedly
the way I came accross. And so some heckling occured, and the whole thing
halted into a gridlock.

After giving it a lot of though, I realized I was wrong on a number of
essential points.

One is that my position should not be that of negotiating the terms of
adding loki to boost. This is both a practical and a social issue, and I
believe there's no need for more discussion about these.

Another mistake I made was insisting on mechanical translation between loki
proper and boost-loki. I decided that mechanical translation should be
dropped if progress is to be made. Loki proper is out there on the net,
people who are reading MC++D can work with it etc. People who want a new and
updated version of loki, a version enhanced by both its initiator and the
community, should look at boost. So basically it is best that I divorce of
the idea that there should be only one point of maintenance for loki.

These two realizations cleaned my forehead of worries quite a lot. Given the
new context, a lot of great things can happen with regard to integrating
boost and loki. But first, allow me to describe the ways in which I believe
boost and loki can benefit of each other.

(1) First and foremost, loki can benefit of everything that the boost
community provides for its codebase: evolving design, support, regression
testing, portability to many compilers, etc.

(2) Some components in loki suck compared to their boost counterparts (type
traits comes to mind. I don't know much about Functor yet.)

(3) Some components present in loki are not in boost (Singleton, Visitor,
Multimethods, etc.) I hope it wouldn't sound like brag if I said that I
believe these are components that, although they can be largely improved,
are reasonably well thought-out.

(4) The much discussed-upon smart pointer in loki can become a
generalization of all boost pointers and offers new capabilities as well
(such as easy implementation of intrusive reference counting, which is very
important for a category of applications). To prevent the reignition of a
discussion, my belief is that it would be best that the two kinds of
pointers coexist, at least until template typedefs make it into the
language. At that point, some specialized smart pointers could be changed
into typedefs without breaking client code.

(5) There is some duplicated work and overlap between loki and boost. It
would be great if we can merge effort instead of creating factions.

(6) Whenever writing new boost libraries, everybody can use both Loki and
boost - specifically, something that I really love is the traits and the
threading library.

This being said, let me address a petition to boost developers. I need help.
More specifically, I would like to cooperate with one or two boost
developers who have a bit of time and enthusiasm to help with the porting
effort. My grad school schedule is vey hectic (as I'm sure you all know,
it's like a job that doesn't finish when you're home) and there are only so
many hours in the day. I won't hide that my participation might be mostly
limited to reviewing code and making (re)design considerations.

We can work together on porting relevant parts of loki to boost, component
by component. While doing so, ideas can flow from all the boost community.
Ideally, the developers would be boost experts so they know about storage,
build system, configuration, compiler support and so on.

What I would hope to see happening is that the conceptual integrity of loki
is preserved - that is, loki's charter and tenets are not mutated to the
extent that I believe it's terrible or it's become a kitchen sink. To this
end, I will try to explain when and why I believe certain proposals should
be avoided. To bring up the thing that led the first integration attempt to
failure, many people were convinced that loki should use mpl, while I
believe - then and now - that it would be better for loki to rely on a much
simpler typelist facility, and to export that typelist facility for use by
other boost libraries and by boost users.

So, if there's anyone who has thoughts on the above and/or wants to
volunteer, please post to the newsgroup (by the way, it's wonderful that we
now have nntp access - the emails were so hard to sift through). Thanks in
advance.

Andrei