Re: [sigc] Proposal for standardization in C++ Library TR2

[Carl Nygard <cjnygard verizon net>]

On Wed, 2005-07-27 at 11:25 -0500, Doug Gregor wrote:
> On Jul 26, 2005, at 11:49 AM, Carl Nygard wrote:
> 
> > On Tue, 2005-07-26 at 17:12 +0200, Murray Cumming wrote:
> >> On Tue, 2005-07-26 at 09:57 -0500, Douglas Gregor wrote:
> >>> On Jul 26, 2005, at 6:37 AM, Murray Cumming wrote:
> >>>> This sounds great to me. Hopefully you can get the document 
> >>>> started, as
> >>>> someone who's experienced with this?
> >>>
> >>> Sure. Some mundanities:
> >>>
> >>> 1) We need version control. If you two send me your sourceforge IDs, 
> >>> we
> >>> can use the boost-sandbox CVS repository at:
> >>
> >> Mine is murrayc
> >>
> >>>    http://sourceforge.net/projects/boost-sandbox/
> >>>
> >>> 2) Any documentation format preferences? LaTeX, HTML, 
> >>> reStructuredText?
> >>> Plain HTML might just be easiest...
> >>
> >> I tend to use docbook, but I can adapt to anything. A wiki would also 
> >> be
> >> nice, but it's not essential.
> >
> > Sourceforge id: cjnygard
> 
> Both of you now have read/write access to the boost-sandbox CVS. I've 
> placed a thin skeleton in committee/sigslot/proposal.html. Yep, I 
> wimped out and went with raw HTML, but we can change it if we have to.
> 
> So, here's big question #1:
> 
> What the heck do we call a signal? I'd like to call it "signal", but 
> that name is already taken in namespace "std". Some other ideas, in no 
> particular order:
> 
>    1) publisher (and "subscriber", for slots)
>    2) event
>    3) delegate
>    4) multifunction (since there's a "function" already in tr1)
>    5) subject (and "observer", for slots; probably too generic)
> 

This is just rambling, in the hope that it spurs more brainstorming.
When I think of a slot, what I actually have is an object that serves as
a proxy for some function.  So, perhaps std::proxy_fun (following the
example of std::ptr_fun and std::mem_fun)?

When I think of a signal, I think of a signal.  Too bad std::signal is
taken.  std::callback might be appropriate, because when you register a
proxy_fun, you're expecting a call back at some point in the future.

Would it be appropriate to bury this two levels deep, because of the
helper objects involved?  Don't know if there are any rules governing
std:: naming. In that vein, one suggestion might be
std::callback::signal, std::callback::connection,
std::callback::proxy_fun?  Ugh, my next comment was going to be "shorter
is better, so multifunction is right out" but I guess one can always use
typedefs...

Some other thoughts:  

'event' reminds me of X events, which is appropriate because they are
really events.  With Sig/Slot, I may just want a way to connect two
classes without creating a dependency, for any number reasons or
purposes.

'delegate' seems to me to be a reasonable description of what is
happening.  One con might be the terminology overlap with GoF delegate
patterns.  

'publisher/subscriber' is nicely generic, and seems to me the best of
the five.

'multifunction' might be pushing it.  I know from my own experience I
tend to use Sig/Slot to avoid dependencies, so it's usually fairly
one-to-one and for me multifunction would not be descriptive of my use
case.

Regards,
Carl