Re: [boost] [GTL] redesign checked into sandbox

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-10 02:39:33

>>> Luke wrote:
>>> Is it valid to call something a concept if there is no concept
>>> checking?
>> 
>> Bruno wrote:
>> Yes it is. 

John wrote:
>Oh, maybe my point of view was too narrow then :)  In _this_ context I
>thought checking was a requirement, otherwise why make a class? without
>checking it is just documentation right?

Um, not in my case.  I am sort of stretching the concept class to serve
additional roles, for instance, making it also the scope within which
functions related to that concept are defined.  When the free function
of the library is called on a user type the related concept is looked up
by metafunction and redirects the call to the function defined within
that concept class.  Also, I'm making no requirements on the user type
except that it provide a default constructor and have an associated
specialization of the traits class to provide accessor functions.  I can
check these requirements with concept checks on each function in the
concept class, of course.

John wrote:
>So what I am interested in is making those assumptions explicit, and
>providing the tools to check that my _own_ private code is going to
work
>with whatever makes it into boost. That is why I say I care more about
>concepts (meaning checkable concepts & archetypes) than I do about the
>algorithms in a boost geometry library.

If your own point type has a default constructor and API sufficient to
get and set the x and y values in any way you like it will work with my
library.  You would simply specialize the point_traits for your type and
provide a typedef for your coordinate_type and two functions, one to get
a coordinate and one to set a coordinate.  

John wrote:
>For my two cents I reccomend:
>
>1. Prefer metafunctions in the point concepts requirements 
>   over traits classes, or I'm afraid the traits will get huge.

If the traits are huge the abstraction is being made in the wrong place.
A good abstraction is a min-cut in a graph of dependencies.  A huge
number of metafunctions seems equally bad to me.  Instead the goal
should be to minimize the number of traits/metafunctions required to be
understood/specialize by the user.

That said I was already leaning in the direction of making the
coordinate_type typedef a meta-function and moving it out of the traits.

>2. Put your concept mapping functions in a namespace rather
>   than a class (do it like like Fusion does).   
>   Namespaces seem to provide a lot more flexibility, and 
>   the syntax is a LOT cleaner.

I am considering the implications of your suggestion.  It could be that
it can be made to work, but I'm not clear on how overloading functions
in a namespace is preferable to specializing a struct.  It seems that it
is more prone to compiler errors related to overloading ambiguity caused
by bad user code and unfortunate combinations of user code.  With the
traits there is no chance for ambiguity.
 
>3. Provide separate headers for each metafunction.
>   This allows users to fucus on metafunctions that matter.

I am doing this already, though there is only one metafunction that
matters right now; the one that maps the user type to its related
concept.

>4. Make all requirements explicit in the concept class. This
>   way I can look at the concept code and see what they are.

It isn't really my intention for the user to look at the concept code.
I don't need the user to fully model the concept such that all functions
can be called on it.  If the user only uses the read only functions that
don't modify or construct their data type they can partially model the
concept if the have to.  (Some programming styles require dynamic
allocation of objects and prohibit default construction, in other cases
the user may never want the library to modify an object of a given
type.)
 
Thanks,
Luke