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@topherc.net> 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