RE: [boost] Named Template Parameters in sandbox

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-08-09 11:43:53

Hi Jaakko,

>> I'm not sure if I understand this correctly, but it looks to me that you
>> could instanciate the following types of car:
>>
>> car< red, blue, black, red > my_very_strange_car;

>Sure you can, and you get a car like:

>model:        red
>color:        blue
>seats:        black
>transmission: red

>assuming that all parameter positions accept either a named or unnamed
>template parameters.

I was actualy assuming the oposite. That none of the positions would take
un-named template parameters. But I had missed that the typedefs in car<>
would prevent this unless the supplied class acidentally supplied the
required typedef. ( eats lots of humble pie and removes foot from mouth to
*probably* make space for the other foot :-( )

>(The test program doesn't and it does in deed behave a bit strangely,
>because of what you pointed out next):

>> This does not seem very desireable. Also, shouldn't the
>> named_parameter_exctractor use is_named_parameter to check that a user
>> supplied parameter is a named parameter.

>Yes, this makes sense. I'll add this test.

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.

>Getting back to car<red, blue, black, red> my_very_strange_car

>Your real car template would do something meaningful with its template
>parameters, and would reject such instantiation at some point.
>Our empty car template has no requirements for its template parameters,
>making this code valid. The NTP mechanism doesn't, and shouldn't, have any
>criteria for accepting certain types and rejecting others. This is the
>task of the car template itself, once the NTP has figured out what all
>the parameters (or features) are.

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.

>> I don't understand why the class discriminator needs to virtually
inherit?
>> As far as I can see, even if the user instanciated car with duplicate
types
>> or the implementer of car used duplicate types, the recursive feature
>> selector will always provide a different integer value.

>Could be, I have to check, but virtual inheritance doesn't do any harm
>either.

Yes. I don't think it does any harm here and it would be needed as each
named parameter inherits form tag and defaults so the discriminator woul get
a copy of tag and defaults for each named template. However, I guess that
once the type has been extracted, the whole thing gets thrown away and this
becomes a compile time optimisation.

>> 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.
2. Option1 and option2 can add diferent member functions to be inherited by
layers that come on top of them.

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 )

>> Personally found it less intuative than the 'C & E' named template
>> parameters and it seems to be at least as verbose.

>What was the 'C & E' NTP solution again?

check-out:
http://www.generative-programming.org/namedparams/

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

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.

thanks for the reply

/ikh