Hello, Doug Gregor wrote:
> 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) before you read on, please note that I'm not a native speaker, so the following might be totally bogus. I think the 'signal' metaphor is broken anyway, because to me a signal is the content of an emission. What's being emitted by both libraries are the parameters to signal.emit/signal.operator(); they are not formalized in both libs and have no special name and right so. I don't understand the slot metaphor either, especially together with signals. What's called signal in both libraries is rather the emitter of the signal, and the same applies to 'event'. So here is a table with alternatives that fit better metaphorically, IMHO that is: 1 | signal | slot | see above --|-------------|--------------------------|-------------------------- 2 | emitter | receiver/collector | too technoid (unless when | | | modelling a transistor;-) --|-------------|--------------------------|-------------------------- 3 | publisher | subscriber | too anthropomorph? --|-------------|--------------------------|-------------------------- 4 | sender | receiver | acceptable? So I'd vote for 4 (if I had earned voting right anyway;-). It also fits quite well to sender.connect(receiver) yielding a connection object. Just my 0,02 €. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com
_______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list