Re: [boost] Tuple review

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-06-18 13:40:24

From: "Gary Powell" <Gary.Powell_at_[hidden]>

> [Ed Brey]
> The nested namespace is quite convenient.  However the namespace name
> "tuples" should be "tuple".  (Better reflects its usage at a given
point
> in a program; it's similar to giving an enum a singular name. Also
> provides better correspondence to the header file name.)
> [Gary]
> I thought the use of tuple::tuple than tuples::tuple would be more
> confusing, especially if the user did a
> using namespace tuple;
> In general I find it easier to read code that has namespaces that are
> different names from the class names.

Aaargh.  Using the plural is out of sync with other namespaces and such
constructs I've come across, but your concern seems quite valid.  I know
that Python tends to have namespaces (in the form of modules) with
functions by the same name.  Is there any wisdom to be gleened from
experience in that corner?

I'm a little confused about your point regarding the "using namespace
boost::tuple" use case.  That seems to be the one place where there
would be no confusion, since after that tuple uniquely means the class,
whereas boost::tuple means the namespace, and the potentially
odd-looking tuple::tuple would never be needed.

Perhaps since the namespace here is nested under boost, rather than ::,
difficulties with identically named class and namespaces won't occur in
this case.

> [Ed Brey]
> set_left and set_right seem likely to cause problems with
right-to-left
> (and top-to-bottom?) languages.  set_open and set_close would probably
> be better.
> [Gary]
> Hmm, I'm unfamiliar with this conflict. Are there any other comments
on
> this?

Just to clarify, the function names assume that the opening bracket of
the tuple will naturally be displayed on the left portion of the line.
In all the languages I've ever studied (English, French, Latin), this is
the case.  However, I understand that there are other languages
(Arabic?) where one normally reads from right to left, and so the
opening bracket would be on the right side of the line.  Of course, the
interface names are in English, but if it's easy to save a programmer
some mental reversals, one might as well if alternative names are
equally clear.

> [Ed Brey]
> nil is undocumented.  It should probably be either documented or moved
> into the detail namespace.  Is the nil/null being proposed as due to
the
> function library discussion compatible with this?  Assuming yes, it
> would seem to keep things minimal to share the single class once it is
> complete.  As far as naming goes, null is standard C/C++ terminology
for
> this concept of referencing nothing when one might otherwise be
> referencing something, and it would be good to use the existing name
for
> this concept.  This is especially true if a C++ 0x might have a null
> keyword that could be leveraged by simply deleting the null class.  If
a
> null keyword would not be drop-in replacement, then it makes sense to
> call the class something besides null (e.g. nil) to avoid a future
> conflict.
> [Gary]
> This got discussed to death on Function, with no resolution yet.
Tuples can
> use the Function version just fine and that is what I've proposed we
do. Yet
> there seems to be some hesitancy to letting function add it without
another
> review. If we could add it soon, I'd be glad to hold off putting
tuples up
> until this is resolved (I'm hoping soon, as in the next review?) But I
don't
> want to wait 6 months on this.

As long as it is in the detail namespace and avoids possible name
conflicts (nil for Mac and null for future C++ keyword (is the latter a
real concern?), I can't see any problems.

> [Ed Brey]
> Documentation:
>
> "Using the library":
>
> It is unclear whether tuple.cpp is needed for tuples in general, or
only
> if tuple input and output operators are used.
> [Gary]
> Just the I/O streams.

I deduced that from the code.  My point was that the documentation
should make the fact more clear.

> [Ed Brey]
> 'tuple<X,X,X>(string("Jaba"), string("Daba"), string("Duu"))' would be
> stronger example as 'tuple<X,X,X>("Jaba", "Daba", "Duu")' (assuming
> that's OK).
> [Gary]
> Hmm.. I'm not sure what you mean by this. How so?

tuple<X,X,X>("Jaba", "Daba", "Duu") demonstrates that implicit
conversion of the arguments is supported.