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

[Roel Vanhout <roel riks nl>]

Murray Cumming wrote:
>  > Thanks for your input! "Signals" definitely does have that confusion
>  > factor with those Unixy signals, whereas "event" and "handler" are
>  > common terminology for this sort of thing.
> I'm disappointed we can't have std::signal (What's using that), but for
> now event/handler seems to be the best alternative.
> Windows coders will be convinced that events are for interprocess
> communication and/or that they all go into a central queue, but they are
> easily confused.

WFIW (being a Windows programmer and not a native English speaker and 
all), I think 'event' is the best. It is a simple word, a word that 
non-native speakers will learn fairly soon when learning English (unlike 
'slot', although of course people who learn English eg in Vegas will 
soon learn about 'slot machines' :) ). Also, the relation between 
'signal' (being a generic 'event' sort of thing) and 'slot' (being a 
groove in something according to Webster) is not one-on-one IMO. Using 
'event' and 'event_handler' would make it absolutely clear that the two 
are a pair.
About confusing 'event' with X events or COM events or any other type of 
events, the same goes for 'signal' and Unix signals. And I also think 
that every term one could come up with is already used by some 
implementation of a signalling framework ('delegate' in .net, 'subject' 
and 'observer' in the GoF pattern, ...).


cheers,

roel