Re: Beyond Objects [was: Re: [boost] Re: review request: container_traits]

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-06 15:32:01

--On Monday, October 06, 2003 2:54 PM -0400 Brian McNamara 
<lorgon_at_[hidden]> wrote:

Mat:
>> Avoid nested types. But also avoid traits classes in an attempt to
>> reify metafunctions. Prefer free metafunctions. We don't need more
>> fat, closed traits classes anymore then we need more fat closed
>> classes.

Brian:
> My point is that a so-called "traits class" need not close off future
> design possibilities.  The way I envision a traits class (or traits
> namespace), is that it simply is a group of ("free") metafunctions
> which are all related by virtue of being members of the same concept.
>
> That is, for each concept (SomeConcept), there should be some type of
> entity (SomeConcept_traits) which has as its members all of the "free
> metafunctions" associated with that concept.
>
> As a result, when Joe-Programmer wants a utility to discover the
> value_type of a container (for any container--even an array), he can
> look in one place--inside "container_traits"--for a (free) value_type
> (unary) metafunction, rather than having to look all over the library
> trying to find the same "container_value_type" metafunction.  (I am
> aware that I am "dramatizing" the issue a bit.)

First of all, thanks for engaging in this thread, and please not that
I have not thought these ideas all the way through, I am just
exploring the space. Now let me see if I understand your points. I
hear you saying two things. First, it seems that you are advocating an
"open" approach along the lines of namesapces as opposed to the
"closed" approach that classes offer. Sounds reasonable enough.
Second, it seems that you would like to collect together metafunctions
that apply to a given concept. This reminds me of the object oriented
perspective and I'm not sure that it is desirable in concept based
design. Consider, for example, a simple concept like Default
Constructible. Would we really want to collect together all functions/
metafunctions that applying to Default Constructible models? I don't
think so. Although this is an extreme example I think that it suggests
that "modules" should be formed around functionality/roles instead if
around the requirements on the models. I need to read up on the design
idioms concerning modules in other languages such as OBJ2, or the ML
family.

[snip]
> A few other points:
>
> Since some concepts (like Container) are closed (the standard says
> what they are; we cannot add new constraints to this concept), it
> does no harm to package the Container traits metafunctions in a
> (closed) class. Once a concept has been defined and come into
> standard use in practice, it is (in any reasonable practical sense)
> already a "closed" entity --regardless of whether the C++ code
> representing this entity is similarly "closed".
>
> That last sentence is important enough that it bears repeating:
>
>    Once a concept has been defined and come into standard use in
>    practice, it is (in any reasonable practical sense) already a
>    "closed" entity.

Hmmm. In my view a (syntactic) concept is a bundle of types,
functions, metafunctions and constraints. I think that concept based
design is more (generic) function-centric then OO design. So the while
a concept may be "closed", the set of generic functions that may be
specified to require that concept is quite open. I don't think of
generic functions as belonging to a group defined by the concept.
Instead I think that modules should be organized around generic
functions with related functionality -- not around the concepts that
the require.

> I don't see how ADL is an issue.  The way I see things, everything
> uses fully-qualified names.

ADL can be an issue sometimes. Suppose I want to write a model of the
boost IncidenceGraph concept. Can I put it it all in my own namespace?
Some answers to this question may require that I call some functions
and metafunctions without full qualification. The question is even
more complicated for namespace std.

[snip]

 - Mat