Re: [sigc] Proposal for standardization in C++ Library TR2
- From: Roel Vanhout <roel riks nl>
- To: libsigc++ list <libsigc-list gnome org>
- Subject: Re: [sigc] Proposal for standardization in C++ Library TR2
- Date: Thu, 28 Jul 2005 10:10:52 +0200
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
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, ...).
] [Thread Prev