RE: [boost] Ready to add dlw_oprs.zip?

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-12-20 08:46:30

Dave Abrahams wrote:

> ----- Original Message -----
> From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
[snip]
> > 7) an important issue - template names; currently they are inconsistent in
> > sense that some of them do follow the standard's  terminology and
> operators'
> > classification, and some of them don't or/and even use the standard naming
> > of operators categories to describe something different; for example,
> > 'additive' and 'mutliplicative' match the standard terminology one-to-one,
> > and 'totaly_ordered' IMO doesn't even come close.
>
> Do you mean that the name doesn't reflect the standard mathematical meaning
> of "total ordering"?

Well, I think it does, assuming that operators < and == have the correct
semantics, I just meant that there is no 'TotallyOrdered' concept defined in
the standard, and that the name stands out from the list of others that are
defined (LessThanComparable, EqualityComparable).

>
> > The list of the names I'm
> > concerned about with some comments:
> >
> >     * 'totaly_ordered' - isn't plain 'comparable' a better choice?
>
> No, I don't think so. IMO, the name should be /more/ specialized that
> "less_than_comparable", not less.

It joins several operator categories, so IMO it should be more generic :).
More specialized for me means something like
'equality_and_less_than_comparable' :), and I think nobody like that one...
BTW, a few weeks ago Jeremy proposed the 'Comparable' concept which matches
our current 'totaly_ordered' template one-to-one. I think having the uniform
terminology across the boost libraries is a nice thing :).

> >     * 'bidirectionally_shiftable' - again, just plain 'shiftable' (5.8)
> > should be good enough and more standard.
>
> I'm not sure. I think the same argument as the one against "comparable"
> applies here.

Well, if we already have 'left_shiftable' and 'right_shiftable', I think that
it's clear that 'shiftable' means the combination of these two, especially
because it's how they are generically (? - not sure if this is the right word
:) named in the standard.

> >     * 'idempotent' - well, there are no standard term for this (at least
> no
> > one that I know about :), and probably it is technically correct, but for
> me
> > it just seem to stand out against all others.
>
> Actually, if http://nightflight.com/cgi-bin/foldoc.cgi?idempotent is to be
> believed, then "idempotent" is almost totally inappropriate.

Indeed.

> I'm glad you
> pointed this out. Can you come up with a better name?

I am sure we can think of something better, but IMO the question is what
naming scheme it should stick to (please, see the explanation below :).

> > Also a question to all, highlighted by the recent discussion of the
> > 'LessThanComparable' concept's requirements ;) - what about renaming the
> > 'less_than_comparable' class template to something else, which will match
> > the standard definition more closely, and deprecating the old name??
> > 'relational' (5.9 [expr.rel]) is not bad IMO.
>
> In what way does the current one not match the standard definition? I'm not
> sure what problem you're trying to fix here.

I'll try to explain (now I think that I even myself realized what issue I was
trying to raise :). Essentially all my concerns come to one following question
(well, two actually ;):

"What the names of the library's class templates are supposed to reflect? What
is their uniform semantics?"

And I am afraid, that at current moment there is no one. See, some of the
class templates, such as 'negatable', indicate the concept (operator(s)),
which will be supported by some class A _after_ that operator's class template
will be applied to it (i.e. A will support 'operator!' only after A will be
derived from 'negatable') ; some other library's templates, and
'less_than_comparable' is one of them, work in the opposite way - if A is
_already_ LessThanComparable, i.e. it defines 'operator<', which returns type
convertible to 'bool' and defines a strict weak ordering relation, then our
'less_than_comparable' template will add another 3 relational operators to it
and make the class to suppport another, less (or is it more?) restrictive
concept that Jeremy calls 'Comparable'; and yet other ones, such as 'addable',
are something in between: there are no standard 'Addable' concept, but I
assume that if it exist it would require both 'operator+=' and 'operator+' for
the class to be defined; assuming that, I'd interpret the semantics of our
'addable' template in this way: if you want the 'Addable' concept to be
supported, you need to implement a particular part of it, 'operator+=', by
yourself, and then the 'boost::addable' operator's class template will do the
rest of the job for you. Nothing wrong with it, of course, but it's the 3-rd
kind of semantics associated with the these class templates' names.

That's why I said that I think that 'less_than_comparable' does not match the
standard definition - I just thought that it was supposed to have the
semantics of 'negatable' (which, I thought was the only one possible :), and
no wonder the whole thing seemed wrong to me.

Well, did I really clarified anything? ;)

[snip]
> > One last meta comment: I am also sharing Dave's concerns about library's
> > grow (given that just recently I citied the library as an example of
> > appropriate layering/splitting into parts :). I think that splitting it to
> > at least three parts (both code and documentation) - basic arithmetic
> > operators, iterator adapters and grouped operators, should be done before
> > the release. If nobody else, I'll volunteer :).
>
> I accept! ;-). Give Daryle a chance to finish all the changes he feels he
> needs to make, then go for it.

Sounds exciting :)

--Aleksey