Re: [boost] [interest] Type Aspects and compile-time constraints

Subject: Re: [boost] [interest] Type Aspects and compile-time constraints
From: Beren Minor (beren.minor+boost_at_[hidden])
Date: 2012-02-09 02:54:58

> I'm still not really getting this. :(
>
> It *looks* to me like you're doing something equivalent to
>
> namespace numeric_tags { /*...*/ }
> namespace packing_tags { /*...*/ }
> namespace order_tags { /*...*/ }
>
> template< class T > struct gl_data_traits;
>
> template<> struct gl_data_traits< gl_unsigned_byte >
> {
> Â  Â typedef numeric_tags::uint8_ numeric;
> Â  Â typedef packing_tags::one_in_one packing;
> Â  Â typedef order_tags::forward order;
> };
> template<> struct gl_data_traits< gl_byte > { /*...*/ };
> /* ...etc... */
>
> I would not consider anything that I typed above to be particularly novel;
> it's basically the same pattern that, e.g., std::iterator_traits and
> std::numeric_limits have. I don't see really any functional difference
> between what I wrote and what you wrote. Clearly there's something "new"
> about your design that I think I'm missing :(

Well, I'm not really saying it is new, I'm asking if it is. Maybe it isn't.
I can see now with your example, that this is very close to the tags
used in the iterator_traits for example (and the other traits if we
consider value_type etc... as axes with not restricted values...).

The idea is maybe that I generalize a little bit this mechanism, and
especially in the way properties are defined and accessed.
Starting from your example, the way to retrieve the aspects of data
type is by accessing gl_data_traits< type >. But this traits type is
valid for data types only as the gl_data_type structure has a fixed
list of traits/tags that are not able to describe anything else than a
gl_data. In my code, if I assume that a given type to have a numeric
aspect, then I'm able to call get_numeric< Type >::type to retrieve
this aspect, whatever type I provide. This is because I have a common
mechanism to define and embed aspects in the types themselves. The
type aspects are embedded in an "aspect" typedef in every type, which
then is expected to contain a "numeric" member describing the numeric
aspect of the type. This is not limited to gl_data type anymore and
the same accessing mechanism can be used with any type that is
expected to have some numeric properties.

That's what I do in the constraint checking code I've pasted above:

 typedef bm::and_< fnum::integral::is_integral<
                     typename fcmn::get_numeric< GroupType >::type
                   >,
                   fnum::integral::is_not_integral<
                     typename fcmn::get_numeric< DataType >::type
                   > > group_is_integral_but_data_is_not;

Using an iterator_traits describing way, this would require to know
what traits type to use with GroupType and which one to use with
DataType to access the numeric properties of these types.

On Thu, Feb 9, 2012 at 1:35 AM, Topher Cooper <topher_at_[hidden]> wrote:
> A non-substantive comment:
>
> I would suggest that you use a different name for this if it goes beyond
> purely personal use.
>
> The reason is that there is a technology called Aspect Oriented Programming
> that is in widespread use and under active research and development. Â In
> general it is an extension to modularization but is usually seen as an
> extension to Object Oriented Programming. Â Many, but not all, of the
> concerns it addresses can be handled in C++ with generic programming,
> mix-ins and (for run time aspects) delegation.
>
> How about Type Axises? Â Seems to capture what you consider distinctive to
> this approach.

I know about AOP, and I know Type Traits was a little bit
misleading... but as I said, it's been chosen mostly by lack of any
other nice name. I'm not very attached to it but I think it describes
well what I want to represent. Type Axes... I'm not linking this as
much. I was thinking of Type Facets, but facets is also already in use
in the standard library.

Actually isn't this description of types over some orthogonal
properties quite close to AOP model? As far as I could remember, AOP
is also about describing a program along orthogonal aspects (such as
security, logging, etc...), right?

-- 
Beren Minor