Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-22 16:03:37

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vgkjo+102eg_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >I've not looked at Jesse's new code yet, but Doug's code doesn't 
seem 
> >to open up the possiblity of runtime errors that you suggest.  
> >Neither does it require that any parameters or other types be 
default 
> >constructible.  Care to elaborate on the problems you think you 
see?
> 
> The compile-time interface to the callback class offers versions of
> operator() that cannot be satisfied at runtime.

Again, I won't comment on Jesse's implementation, but it's possible 
to implement this idiom with the result of it being a compile time, 
not run time, error to use an erroneous operator() overload.

> >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 understand that the syntax is desirable, but I don't think it 
should
> be at the expense of safety.

I'd agree, but I don't see safety issues here.
 
> It should be possible, with appropriate specialisations, to make the
> unwanted overloads of the callback unusable for a given number of
> arguments.

It doesn't really even require specializations, though it does 
require some meta programming.  Doug's version is already safe in 
this regard.
 
> Another thought: Would it be possible to do a little currying to 
wrap up
> the way that extra arguments are handled internally? This would 
have the
> benefit of (1) enforcing only legal use, (2) simplifying the
> implementation, and (3) keeping the size of classes and number of
> virtuals flying around to a minimum.

Again, I think Doug's addressed this fairly well.  There may yet be 
some tricks to reduce code bloat in his implementation, but in 
general it's satisfactory now.

Bill Kempf