On Fri, 2005-07-29 at 13:41 -0500, Doug Gregor wrote: > On Jul 29, 2005, at 11:06 AM, Lars Gullik Bjønnes wrote: > > I think there is more than two names that needs to be decided on. > > > > With signal/slot we have at least: signal, slot, connection and emit > > (wheter the explit emit will be in the standard or not is a different > > subject) > > > > For publisher/subscriber this could be: publisher, subscriber, > > subscription and publish > > > > Are there other concepts in this framework that needs to be named? > > There's the "trackable" class, which could potentially get a different > name, but it doesn't have to. Signal, slot, and connection are the big > ones. > > Murray, Carl: How do you feel about this terminology?
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. Regards, Carl _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
