Re: [boost] [parameter] some extensions to Boost.Parameter

Subject: Re: [boost] [parameter] some extensions to Boost.Parameter
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-10-30 11:41:31

On Wed, Oct 29, 2008 at 4:34 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Tue Oct 28 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
>>
>> I have found that the direct use of ArgumentPacks makes this
>> inheritance-chaining design quite nice/clean to implement.  AFAICT,
>> using the macro-based interface would have required two classes per
>> view/behavior (an implementation class, and a class that uses
>> BOOST_PARAMETER_CONSTRUCTOR) - this is because any of these classes
>> can be the top-level class.  That alone was reason enough for me not
>> to investigate that route further - I'm not sure whether any
>> difficulty would arise from having to specify that a class can receive
>> a parameter intended for it, or intended for the base class.
>
> I don't see why that means the top-level class needs to have an
> ArgumentPack ctor.
>

Every class needs a constructor that takes an ArgumentPack because it
can be inherited from, and needs to be able to receive the
ArgumentPack from the derived class.  If I wanted to allow users to
call the constructor in a more friendly way, then every class that
could be a top-level class would also need a constructor like you
suggest below (and 'every class' would need to turn into a pair of
classes because we can't delegate to another constructor in the same
class, no?).

Ideally, I would want to allow things like this:

typedef
        view::solid_background<
                view::positioned<>
    >  colored_block;

some_window << new colored_block(...);

BUT... I might have other reasons why I might require a boiler-plate
top-level class, in which case I might do something like what you
suggest below.

> class button : public button_base_type
> {
>  public:
>     typedef button_base_type base_type;
>
>     // takes up to 12 parameters
>     MY_GUI_GENERATE_CTOR(button, 12, button_base_type);
>

does MY_GUI_GENERATE_CTOR expand to

template<typename T0>
button(const T0 &t0)
  : button_base_type((t0))
{}

template<typename T0, typename T1>
button(const T0 &t0, const T1 &t1)
  : button_base_type((t0, t1))
{}

...

?

[...]
>
>> and I don't know how to take advantage of, e.g., deduced parameters.
>
> They are only applicable when the types of possible arguments are
> sharply distinct.  Is that your situation?
>

No, I was just curious in general.

>>>> Here are brief descriptions of the extensions:
>>>>
>>>> *1* Keywords/Tags with fixed types
>>>> These are intended for keywords/tags that are always associated with a
>>>> certain type of argument.  operator= of a fixed-type keyword always
>>>> return a tagged argument whose value_type is the fixed type.
>>>>
>>>> This has the benefit of moving any type conversions to the call site,
>>>
>>> Might be interesting if we can integrate that into the macros for the
>>> cases when you specify a fixed type.  This sounds vaguely similar to
>>> what we have to do for the Python binding functionality, except that we
>>> do the "type fixing" post-facto.
>>>
>>
>> I think this would be relatively easy and safe (in a non-breaking
>> change sense) to add in.
>
> Looking forward to seeing that.
>

I'm sorry, I think I misunderstood your comment.  I thought you were
talking about adding something to the library that allows things like
BOOST_PARAMETER_TYPED_NAME(arg, int) - which is easy and I have done.
But are you talking about

BOOST_PARAMETER_FUNCTION(
      (void),
      foo,
      tag,
      (required (arg, int) )
      (optional
        (arg2,           double, 1.5)
      )
  )

... and how the expansion of that could be altered?  I looked at the
preprocessing file but got pretty lost, I think it might take me a
while before I understand how it works.

[...]
>
>>> Ohhh.... so you're saying any two argument packs with the same keywords
>>> and types would be inter-convertible, regardless of argument order?
>>> That makes some sense.
>>
>>
>> Yes - a source pack could be converted to a target pack type as long
>> as the source contains a superset of the tags needed for the target
>> (or any missing tags have a default-default value).
>
> And, I hope, the types of the source pack have to be convertible to
> the types of the target pack.
>

I've been using this with typed keywords, in which the types should be
identical if the tags match.  When conversions are necessary, because
tagged_argument stores the argument by reference you end up with a
dangling reference because the converted temporary goes out of scope
before the function actually gets called.  If you wanted conversions,
you would need tagged_argument to store by value at least in this case
(in which case it might be more efficient for arg_list to store the
tagged_argument by reference... but I'm not sure whether that would
run into the same temporary lifetime problems or other issues).

[...]

>>
>> Yes, there is overlap.  If deduced parameters were available (are
>> they, without the macros?),
>
> Yes.
>

How?  In order for the following to work:

window (( size_type(100,100), position_type(0,0) ))

...I would at least have to overload the comma operator for these two
types to return... what?  Or, if I used something like the
MY_GUI_GENERATE_CTOR macro and took `window (size_type(100,100),
position_type(0,0) )`, how does the constructor assemble the
ArgumentPack from the two types?

Best,

Stjepan