On Friday 23 February 2007 14:23 pm, Peter Dimov wrote:
signal.track( p ).connect( bind( f, p.get() ) );
or, with some bind syntactic sugar added:
signal.track( p ).connect( f, p.get() );
The slot-based formulation could look like:
signal_type::slot_type( bind( f, p.get() ) ).track( p ).connect_to( signal );
or
signal_type::slot_type( f, p.get() ).track( p ).connect_to( signal );
Both seem passable, the first alternative looks a bit more natural. The second has the advantage of potentially producing a reusable slot class that can operate without a signal (if we get its interface right).
Ah, now were getting some convergence. I prefer the second, because it is nearly what I'm promoting, except you've moved the signal/connect to the end, where I would have done: signal.connect(signal_type::slot_type( f, p.get() ).track( p )); However, my way also allows track() to be called an arbitrary number of times before connecting the slot. How would multiple tracked objects be handled with a track(p).connect()/.connect_to() syntax? If you allow track to take varying numbers of arguments, it requires the user to know how many tracked objects there will be at compile time. Being able to call track() multiple times only requires knowing the number of tracked objects at run time, which might be handy if the tracked objects are being collected in a container. I suppose you could overload track to accept a container argument. Also, support for the first alternative could be easily implemented using the second, since whatever object is returned by signal::track() will have both a reference to the signal and the slot in its connect() function. -- Frank