Re: [boost] Re: New New Callbacks Uploaded

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-22 18:17:55

>> As for why it's desirable... it eliminates redundant information from
>> the declaration.  Why should you have to specify the number of
>> parameters when you declare the type with explicit parameters?  It's
>> just cleaner to say:
>>
>> callback<void, int, float> cb;
>>
>> instead of:
>>
>> callback2<void, int, float> cb;
>
>I really don't agree with this.

I was doubtful at first, but I'm starting to warm to the idea.

>1) All of the classes written to
>hide the extra arguments inevitably show up when an error occures
>thus spitting something like this to the user...
>
>  an error has occured in class callback<void,int,float,unused,unused,unused>

Sure, there's a bit of extra noise in the error messages, but that's hardly
a reason to discard the idea.

>2) Second it makes for really poor code clarity as the class will
>have to implement all of the operator() even through it uses
>only one of them...
>
>  class callback {
>    ...
>    return_type operator()() { ... }
>    return_type operator()(P1 p1) { ... }
>    return_type operator()(P1 p1,P2 p2) { ... }
>    return_type operator()(P1 p1,P2 p2,P3 p3) { ... }
>    return_type operator()(P1 p1,P2 p2,P3 p3,P3 p3) { ... }
>    ...
>  };

OTOH you have one callback class instead of 8 or so.

>3) It only saves one charactor. :-)

Yep

>4) It bars adding additional optional arguments which may be
>useful.  Ie,  since the callback may be unconnected how do we specify
>what to return in case of there is nothing connected.
>
>imagine this
>
>  template <class R, class P1, class P2, class RT=trait<R> >
>  class callback2
>    {
>      R operator()(P1 p1,P2 p2)
>        { if (empty) return R(RT::default_value); ... }
>    };
>

I don't think this sort of thing belongs in the callback class. But it's
certainly possible to build more sophisticated classes on top of basic
callbacks...

>6) It encourages gobs of template land meta programming which can slow
>some compilers to a grinding halt and is some of the least portable code
>back to the weaker compilers.  ( Read we will get something which
>VC++ likes but is kludgy as all hell.)  Then again implementing
>many levels of class can do the same.

Maybe, but even MSVC will improve at some point. :-)

  -- Jesse