$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-11-19 19:01:28
At 03:13 PM 11/19/2001, Andrei Alexandrescu wrote:
 >I was hoping yesterday to finalize changing the typelists code to submit 
it
 >to boost for review. I ran into a couple of problems and I said I would 
ask
 >you about that:
 >
 >* What namespace should I put typelists in? The initial placement was: 
the
 >Typelist class was in namespace Loki, and the afferent manipulation
 >functions were in Loki::TL. I was thinking of putting typelist in boost,
 >and the rest in boost:tl. Would that be ok?
The usual practice is to put the public names in namespace boost, and then 
implementation details not part of the public interface in boost::detail.
 >* This brings the point of identity. At a point I plan to have boost (the
 >Borg :o)) swallow all of Loki, but then there would be no Loki anymore. 
Any
 >idea on how to address this identity crisis?
Since Loki is well known, and your book describing it will presumably have 
a long life, you might want to consider leaving that code more or less 
unchanged the Loki name, and still available at its current web locations.
Then as far as submissions to Boost go, you can be free to change the code 
(which is in namespace boost) as you get feedback, without in any way 
abandoning current Loki users.
Long term, perhaps you can address the identity crisis via documentation 
and comments, in the same way that the names "Standard Template Library" 
and STL are still alive even though that actual library has been submerged 
into the C++ standard for years now.  Keep the Loki name alive.
Regardless of the details, the important thing for all potential Boost 
contributors to understand is that we don't require them to merge their (or 
their library's) identity into a faceless Boost monolith.  People are 
important at Boost.  That's why we have individual names on copyright 
messages, acknowledgements in docs, the www.boost.org/people/people.htm 
pages, and in general try to treat libraries as human artifacts, and not 
something a robot produced.
Because of time pressure, I'm going to have to let others answer the rest 
of your questions.  Hope the above helps,
--Beman