Re: Tuples Library Formal Review

From: jaakko.jarvi_at_[hidden]
Date: 2001-06-19 12:10:21

Wow, what a lot of comments!

>  "To use the library, just
> 
>  #include "boost/tuple/tuple.cpp"
>  "
> 
> - Should ".cpp" be ".hpp"? (The same question for other cases in the
> documentation.)
Ok.

> 
> - Should boost headers use the #include <> form?
This seems to be the boost convention, and we can change to that.
(We were once adviced against this by Stroustrup, the claim
was that using <> was somehow non-standard. We took his word
and didn't think it further.) 

> 
> 
>  "The code:
>  tuple i;
>  tuple j;"
> 
> - Are the variable definitions of i and j as intended?
Nope, will be fixed.

> 
> - Is the name "Droug Gregor" spelled correctly?
Nope, will be fixed.

> Design & Implementation
> =======================
> 
> - Should include guards have the word TUPLE in them to distinguish 
them from
> other Boost headers?
The intention was that they would be of the form
BOOST_TUPLE_...

I'll check that they all are.

> 
> - Should the separation between interface and implementation of the 
library be
> made clearer?
Can you be more specific.

> 
> - Should IF<> and other implementation helpers be in the detail 
namespace?
Ok. Or I'd really like to use a boost metaprogramming library
when that becomes official :)

> - 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?
cons is part of the library.
Sometimes you may want to use the cons list view to the tuple, 
for instance while writing functions that operate on tuple
elements (see tuple_io or the comparison operators).

nil is part of the interface in the sense, that the cons list
type of an empty list is nil (once we add the empty tuple,
and change the name of nil to something else)

Other non-detail stuff will be documented.

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

> 
> - 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?
No, we need to be able to provide actual objects as default arguments
in the tuple constructor.

> 
> - 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?
I must think of this. Maybe, unless we want nil to be the underlying 
cons list for the empty tuple.
 
> - Should the number of elements that Tuple supports be easily 
configurable?
We had a set of macros for this, your preprocessing library could
be of help in this.
What do others say?

> 
> - Should indexing from 0 to n-1 be supported? Isn't 0-based indexing 
more
> intuitive in C++?
This is a matter of taste. Others?

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

I must stop here, as I'm out of time for today.
More later.

Thanks a lot for the comments, 

Jaakko

> 
> - 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_a...>
> To: "Boost.org mailing list" <boost_at_y...>;
> <boost-announce_at_y...>
> 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_y...>
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
> >
> >
> >