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

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-06 20:07:44

On Mon, Oct 06, 2003 at 01:32:01PM -0700, Mat Marcus wrote:
> 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.

Actually, I am more trying to advocate "an approach".  Up until earlier
today, it didn't matter to me whether the approach was closed or open.
Then I finally understood one of David's key points, which may
necessitate open-ness (I haven't thought it through yet to decide if it
does).

Again, the overall point is, if we have already gone through the
trouble to define the Container concept--that is, to say that
value_type, iterator_type, etc. are all members of the Container
concept, then it makes sense (to me) to group all of the metafunctions
(which are accessors for those types) into one entity which features
the word "container" in its name.

> 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. 

I don't think so either.  However, ...

> 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 don't immediately jump to this conclusion (based on just the
DefaultConstructible example).

Which is not to say that your conclusion is wrong--it may in fact be the
right one, and I think it sounds at least somewhat along the same lines
as what David has been arguing.  I just am not yet convinced.

> >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.

I think we are in total agreement here.

> Instead I think that modules should be organized around generic
> functions with related functionality -- not around the concepts that
> the require.

Assuming I understand what you mean my "module", I think we agree here,
too.

Maybe another way to state my point is that I see container_traits as a
"concept wrapper" rather than a "module".  It takes a concept (as
described by, e.g., the standard) and wraps it in a more convenient and
generic interface.  This allows more types to model the concept (e.g.
an array can be a Container when viewed via container_traits) and
provides a single named entity which clients of the concept (e.g.
generic functions) can use to get at the concept attributes.

> >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.

You're probably right; I had my traits/types blinders on, and forgot
about entities along the lines of
   namespace container_traits {
      template <class Container>
      R begin( Container c );   // default impl: return c.begin();
   }
In theory I feel like you can always get by with only fully-qualified
calls, but in practice I imagine maybe not.  :)  Thank goodness (or
Jaakko) for enable_if.  :)

-- 
-Brian McNamara (lorgon_at_[hidden])