On Wed, 2005-07-27 at 11:49 -0500, Doug Gregor wrote: > On Jul 27, 2005, at 11:42 AM, Paul Davis wrote: > > > On Wed, 2005-07-27 at 11:25 -0500, Doug Gregor wrote: > >> 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) > > > > event++ > > It'd have to be just "event", because it needs to be the name of the > class template akin to "signal" or "Signal". > > > i've always disliked the way that the terminology "signals and slots" > > hides what is actually happening, and makes it hard for some > > programmers > > to understand what this is all for. personally, i'd love to see "event" > > and "callback" or "event_handler" for slots. > > 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. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list