Re: [boost] [vault] polymorphic_function call wrapper

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-05-28 20:48:54

On Wed, May 28, 2008 at 6:51 PM, Sohail Somani <sohail_at_[hidden]> wrote:
> Daniel Walker wrote:
>> On Wed, May 28, 2008 at 1:07 PM, Sohail Somani <sohail_at_[hidden]> wrote:
>>> Daniel Walker wrote:
>>>> Hello,
>>>>
>>>> Following up on several discussion over the last few weeks, I've
>>>> placed an implementation of a polymorphic call wrapper (and associated
>>>> utilities) similar to Boost.Function in the file
>>>> polymorphic_function.zip in the Function Objects directory on vault at
>>>> http://tinyurl.com/56zvo4.
>>> For those of us just joining, can you please give the main motivation
>>> for use of this new type? I hear polymorphic function and think many
>>> things, none of which may be close to the truth.
>>>
>>> Thanks.
>>
>> Sure. The short answer is that for an instance of boost::function, the
>> return and argument types are fixed, whereas for an instance of
>> polymorphic_function, they may vary. So, polymorphic_function allows
>> you to deal with arbitrary callable object types without being forced
>> to fix the return and argument types if one of those arbitrary
>> callable objects happens to have a templated or overloaded operator().
>
> Great explanation, thanks.
>
> So barring the do_division example, does it solve an existing problem?
> I'm not saying it isn't useful, I'm just trying to figure out if there
> is a problem I have currently that I could use to solve this or whether
> there are a greater class of problems we can now solve easily because
> this class exists.

Good question. I suppose you could say that using polymorphic function
objects interchangeably with builtin functions is currently
problematic, because you loose any benefit of having a templated
operator() as soon as you call wrap it in boost::function. But really,
since you could never invoke call wrappers polymorphically before, I
suppose this opens up a new class of problems that can now be
addressed. Probably a better way to put it is that boost::function
gives you one category of call wrapper, and polymorphic_function
introduces a new category of call wrapper that supports a larger set
of use cases. For example, "overriding" the compiler's argument
deduction with functional_cast is a new use for call wrappers.
functional_cast may be easier to use than the current
boost::function::target member, but when combined with
polymorphic_function it also introduces new use cases: Essentially, it
allows you to restrict argument type deduction or change restrictions
multiple times. (Really, you're changing the types used in argument
forwarding.) In the example of my demo, polymorphic_function and
functional_cast were used to defer type erasure and could be used to
re-erase a function object multiple times with multiple call
signatures, because polymorphic_function, unlike boost::function,
doesn't force the user to erase the callable object at instantiation.
I think these are all new use cases.

Daniel Walker