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

[Jeff Franks <jcfranks tpg com au>]

Carl Nygard wrote:

> [snip]
>
> I've made my thoughts known on this.  The only problem I have with
> publisher/subscriber is that the class (formerly known as Slot)
> std::subscriber isn't *really* the subscriber, it's just a link to the
> actual subscriber.  Hence the naming of std::proxy_fun as the Slot
> object.
>
> However, if no one has jumped on that bandwagon, I'll not stand in the
> way of consensus.
>
> So we'd have:
>
> std::publisher
> std::subscriber
> std::connection
> std::trackable
>
> I'd be curious to see how close libsigc++/Boost.Signals is to the
> idealized GoF Publisher/Subscriber pattern (not that I want to induce
> feature creep).  I thought I had the book here in my library, but I
> guess it's at work.  Oh well, excuse to go to Borders and grab a
> cup-o-joe.
>
>
>  
I have to agree with Murray, I would prefer the term 'event' for a 
signal. The term event has been synonymous with signal for a long time. 
It's short and easy to write and will make source code just that much 
more legible. I've always used the terms 'signal/slot' so these terms 
make sense to me. 'publisher/subscriber' makes me think of magazines and 
newpapers. 'delegate' makes me think of .Net.

What about:

std::event
std::slot
std::connection
std::trackable

The only use of 'slot' I could find is as a local variable in a function 
in 'tr1/hashtable'.

My 2 cents worth,
Jeff Franks.