Re: [boost] Tuples Library Formal Review

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-19 11:29:44

FYI: I have, in fact, read the other reviews, and have omitted some issues
from my comments that I found in other reviews. However, if the following
review mentions issues that have been previously found just ignore them.

...

I think that the Tuple library should be included in Boost. Tuples are a
widely useful concept - in fact, I'm working on a design (abstract syntax tree
generator) that could make use of the concept.

I have phrased the following comments in question format. The idea is that the
library author and others answers those questions publicly. Many of the
questions are such that the answer involves trade-offs rather than absolute
truths. The design of the library should make those trade-offs explicit,
because otherwise the design of the library can be seen as an accident rather
than a carefully crafted solution. It has also been suggested that review
comments should be made in question format, because they are often considered
less threatening.

The following review is based on reading the documentation carefully and
analyzing the source code of the library statically. I have neither compiled
nor executed the example code or used the tuple library, however I have
personally implemented and briefly used a subset of tuple functionality (on
MSVC++) a long time ago (inspired by JJ's article on tuples), so I consider
myself to be sufficiently familiar with their implementation and use.

...

Documentation
=============

 "To use the library, just

 #include "boost/tuple/tuple.cpp"
 "

- Should ".cpp" be ".hpp"? (The same question for other cases in the
documentation.)

- Should boost headers use the #include <> form?

 "The code:
 tuple i;
 tuple j;"

- Are the variable definitions of i and j as intended?

- Is the name "Droug Gregor" spelled correctly?

Design & Implementation
=======================

- Should include guards have the word TUPLE in them to distinguish them from
other Boost headers?

- Should the separation between interface and implementation of the library be
made clearer?

- Should IF<> and other implementation helpers be in the detail namespace?

- Are cons and nil part of the interface of the library? Should they be
documented? What about documenting other stuff not placed into the detail
namespace?

- Should a separate forward declaration header, e.g. tuple_fwd.hpp, be
introduced to help avoid unnecessary compile time dependencies?

- Could void be used instead of nil? If not, why not? Using void might change
the interface a bit. Would the changes have adverse effects?

- If all tuple template type parameters, and the second type parameter to
cons, were nil by default, would it be possible to remove nil from library
interface?

- Should the number of elements that Tuple supports be easily configurable?

- Should indexing from 0 to n-1 be supported? Isn't 0-based indexing more
intuitive in C++?

- Should element_type<> use private to hide the Next type? What about similar
issues in other implementation classes?

- Could get() implementations be simplified by moving the metafunction call
typename element_type<...>::type into the access_traits?

- Could logic duplication be reduced in tuple_comparison.hpp?

- Should TAB characters in tuple_basic_no_partial_spec.hpp be replaced with
spaces?

- Should all headers included by tuple.hpp check that they are not included
separately?

- Should map_tuple_to_cons<> have the same interface for both with and without
partial specialization? If not, should it be in the detail namespace?

- The tie and make_tuple implementations are highly repetitive. Wouldn't it be
possible to reduce the code size significantly, for instance, by moving the
repeated metafunction calls inside an auxiliary metafunction?

- Is "explicitely" a type in the code comments?

- Could implementation be shared between partial and non partial
specialization versions? Should that be done?

- Would it be useful to have a clearly specified and documented
metaprogramming interface for creating and accessing tuples?

- How can a metaprogram compute a tuple type based on a variable length type
list or otherwise computed set of types? Can the process be simplified?

- How can a metaprogram compute the type of the Nth element of a tuple? Should
this be documented?

- How can a metaprogram detect that a type parameter is a tuple type? Should
this be documented?

- How can a metaprogram compute the number of elements of a tuple? Should this
be documented?

- Would it be useful to provide a manipulator for changing all the
configurable behaviour of tuple streaming at once?

Additional comments
===================

Lexicograhical ordering is not the only useful ordering model. Other
frequently useful models include:
- ordering based on only a subset of elements (e.g. key-value pair)
  - note: std::map<K,V>::value_type suffers from this problem
  - for this reason, I use neither tuple nor pair in my container library.
- dominance:
    A<B if a(i)<b(i) for all i

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: "Boost.org mailing list" <boost_at_[hidden]>;
<boost-announce_at_[hidden]>
Sent: Sunday, June 17, 2001 17:13
Subject: [boost] Tuples Library Formal Review

>
> The Formal Review period for Jaakko Järvi's Tuples library begins today,
> and runs through Tuesday, June 26th.
>
> The library is available at
> http://groups.yahoo.com/group/boost/files/Tuple/tuple-2001-05-29.zip
>
> For information about submitting a Formal Review, see
> http://www.boost.org/more/formal_review_process.htm
>
> Be sure to say whether or not you think the library should be accepted by
> Boost.
>
> The Formal Review manager is Beman Dawes.
>
> --Beman
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>