RE: [boost] Named Template Parameters in sandbox

From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2002-08-09 13:17:26

Hi Iain, 

> even with this, I think that it will still take Model_is< red >, Color_is<
> leather >, Seat_is<automatic >, Transmission_is< glx > which will also give
> a very strange car.
> 
<snipped>

> 
> I'm not sure that we agree here. I believe that in order to produce a libray
> that is useful, it needs to encompass a majority of 'use cases'. Validation
> of or constraint of template parameters was the motivation behind the
> concept_check lib and is, I beleive, an essential part of the named
> parameters pattern ( not necessarily lib - but it would be nice ). This
> could be done by requireing the model classes to include typedef's of the
> form:
> 
> struct gl
> {
> 	typedef gl Model;
> };
> 
> and following this through into the Model_is class.

One can't in general require anything from the classes that are 
passed into a template using an NTP scheme. For example, we could
have something like:

stack<element_type_is<int> >

Now, we cannot introduce any typedefs into int.

But obviously one can expand the Feature_is templates (Model_is, 
Color_is etc.) and build arbitrary concept checking into them.

E.g.:

struct gl : public car_model { std::string name() { return "gl"; } };
struct glx : public car_model { std::string name() { return "glx"; } };
struct limited : public car_model { std::string name() { return "limited"; } };

template <class T> struct Model_is : virtual public 
default_car_features
{ 
  BOOST_STATIC_ASSERT(( 
        boost::is_base_and_derived<T, car_model>::value));
  typedef T Model; 
};

> 
> >> You can't do GenVoca layering with it to create communicating policies,
> and
> >> you can't use a parameter to inject a member function into the class. It
> is
> >> also going to require an instance variable for each
> >> named_template_parameter.
> 
> >Could you elaborate, with examples, all these three points.
> 
> 1. layering policies via templates looks something like this:
> 
> template < class Config >
> struct base_layer
> {
> 	typedef Config config;
> 
> 	// members common to all layers go here
> };
> 
> template < class Base_layer >
> struct layer1_option1
> {
> 	typedef Base_layer::config config;
> 
> 	// add some responsibilites
> };
> 
> template < class Base_layer >
> struct layer1_option2
> {
> 	typedef Base_layer::config config;
> 
> 	// add some responsibilites
> };
> 
> and so on. the 'C & E' example shows this in more detail on the link below.

Yes, but I still do not understand the relation of this and NTPs.
To me NTPs and GenVoca layering seem like orthogonal issues.

> 2. Option1 and option2 can add diferent member functions to be inherited by
> layers that come on top of them.

Yes, they can, but again, what is the relation to NTPs.

> 
> 3. In your current example of car. The car object would normally needed
> member variables model, color, seats, and transmission in order for car
> member functions to operate on them. Assuming of course that they would
> maintain state to be interesting ( as they currently don't )
> 

The NTP parameters are just types 
(or integral constants or other nontype 
template parameters). Just as normal template parameters, the template 
class is free to do anything with them. The car example was chosen for its
set of concrete features. One wouldn't really use a 
template parameter to represent a color in a car-object. 

> I believe that they were the originators of this technique and should
> probably be cited in your documentation. ( but I guess Jeremy and Dave A are
> more authorative on this ).
Yes, I'll add a note on that.

> 
> My current preference could just be a greater familiarty, but this is
> something that greately interests me and I would love to see a lib in boost
> that made implementing NTP easier. I was also probably also initially
> exspecting a little more support for the pattern than is currently there. I
> don't currently have any concrete suggestions but I off on a weeks vacation
> next week and will give it some thought.
> 

The library in the sandbox provides a solution to the NTP problem, namely
provides a way to pass types and constants into a template class so that
the mapping between actual arguments and formal parameters is base on the 
names rather than position in the template argument list.

GenVoca etc. are interesting techniques and it'd be nice to have 
libraries/guidlines for implementing such designs in Boost as well, but
that is a different issue from NTP.

Best Regards, Jaakko