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

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-12-21 10:12:00

Dave Abrahams wrote:
> Looking at the names we
> currently have, what most have in common is that the templates "complete
the
> concept" they're describing by filling in missing operators. I don't think
> it's a problem that we don't have standard Concepts for most of these
> things. We shouldn't be trying to define them here, either.

I agree.

> Let's think in
> terms of "concepts" with a small "c".

I like this one. We can make a slogan from it, you know :).

BTW, I just realized that 'negatable' class template is pretty much useless,
because if some class is already convertible to 'bool' (which is the
requirement of the template), you already can write 'if (!some_class())' -
no need to inherit from 'negatable'. It's a pity, because it was a pretty
name ;). But, on the other hand, now we have only two kinds of operators
names' semantics ('cause I believe that 'negatable' was the only pure
representative of "implement the concept from scratch" kind of templates),
so if things will continue to go in this way, soon there will be no problem
:). On second thought, actually 'idempotent' template is even more pure,
because it does not require _anything_ from the class it is applied to; but
by its name it should be categorized to the same category as
'less_than_comparable', so still 2 categories remain :)

As for a proposal for a consistent naming scheme - I am not sure that the
following is quite that, but at least it's something ;) :

1) a name of each operator class template indicates a concept (with a small
'c' <hyperlink to note #1>) which will be supported by a target class after
applying that template to it (e.g. after inheriting from the template, there
are also some other ways);
2) the concept can be a compound one, i.e. represent a common combination of
other, more primitive concepts;
3) to implement the concept most of operator class  templates will need a
certain support from a target type they will be applied to;
4) the degree and type of the required support depend on the concept, but
usually an  implementation of one of the operators of the concept is
required;
5) which operator needs to be implemented is described in the library's
documentation (below?), but, in correspondence with a widely accepted coding
style rule (reference to GotW#4, Herb's book or whatever :), in most cases
it's an assignment counterpart of the "main operator" of the concept  (e.g.
it's 'operator+=' for the 'addable' concept), if applicable;
6) thus, although there are no direct reference to the requirements of the
operator class template in its name (i.e. you write 'addable', not
'addable_on_top_of_plus_assignment'), usually it's pretty easy to figure
them out (and they are described in the documentation :).
7) summarizing the above: "each operator class template completes the
concept(s) it is describing by filling in target class' missing operators,
implementing them on top of the existing one(s), if any are required".

Note #1: concepts we are talking about here are not necessary the standard
library's concepts (CopyConstructible, etc.), although some of them are (?);
in particular, they are different from the former ones, in that they _do
not_ describe a precise semantics of the operators they require to be
defined, expect that the semantics between the operators grouped in one
concept should be consistent (e.g. effects of 'a += b' and 'a = a + b'
expressions should be equivalent), and the return types of these operators
should follow semantics of return types of corresponding operators for
built-in types (e.g. 'operator<' should return a type convertible to 'bool',
or 'T::operator-=' should return type convertible to 'T'). Such "loose"
requirement make operators library applicable to broader set of classes from
different domains, i.e. eventually more useful.

Given that all the above makes sense, I believe that 'less_then_comparable'
and 'equality_comparable' templates are the only ones left <g> :) which does
not match the described principles. What do you think?

Ok, the last remark, what do you think of 'plusable' as a replacement of
'idempotent'? (in the light of the above, of course :)

  --Aleksey