On 7/29/05, Ames Andreas <[EMAIL PROTECTED]> wrote: > Hello, > > Douglas Gregor wrote: > > > On Jul 26, 2005, at 6:37 AM, Murray Cumming wrote: > >> Personally, I don't see anything in the boost::bind API that I > >> dislike, though the "disconnecting all signals of a certain group" > >> on that page is a little odd. > > > > Everything that concerns "named slot groups" should be removed from > > the Boost.Signals API and should not make it into the > > proposal. Named slot groups have caused a *huge* amount of pain on > > the implementation side, and have caused Boost.Signals to be much > > less efficient than it should be. > > does this mean, that the Standard proposal will contain no possibility > to impose a prioritising on the calling sequence of slots (besides the > sequence of signal.connect calls)? > > IMHO that would be unfortunate, because I think this is one of the > advantages of Boost.Signals over libsigc++, to have a well defined > means to do exactly that. One possible application is for library > writers to be able to prioritise internal slots over user defined ones > (which means at least to have two groups of slots). OTOH, I have no > real use for signal.disconnect(group_type) (and also > signal.disconnect(slot)). Would dropping just these diconnect methods > help mitigating the implementational woes you described above (I > haven't yet looked at the implementation, sorry). > > I've also got some other (unrelated) points to ask about: > > 1) Boost's signal.connect documentation states explicitly that > connecting a slot during the emission of the same signal doesn't > guarantee either whether the slot is called for the first time > during the current emission or during the next emission to follow > (which is, IMHO, better than trying to guarantee the call during > the current emission). I didn't find any assertions of this kind > for the disconnect. How will it be handled? > > 2) Similarly I found some statements about recursive signal emission > in Boost's docs. Unfortunately I haven't understood how they are > managed (like whether the recursive emission is postponed to after > the end of the current emission, or whether the recursive emission > is interspersed into the current one). Furthermore I don't > understand the relation of connects and disconnects to recursive > emissions. Would you be so kind to explain me how it (should) work > (now and in the standard)? > > 3) I think its clear that connect/disconnect during emission and > recursive emission together with the promise of future versions > being able to be used in a multithreaded setting (Boost FAQ 2) can > easily become a meal that is hard to digest for the user (and I'm > certainly not the first one to recognise this;-), especially asthe > user currently doesn't seem to be able whether a signal is emitting > at a given point in time. I see two possible extreme positions > here: > > a) Anal retentive: connect during emission is guaranteed to only > invoke the slot *after* the current emission, disconnect during > emission is guaranteed to never call the slot again (when > disconnect returns) and recursive emission is not allowed. > Unfortunately these would impose serious limitations on the > user. > > b) Liberal: no guarantees about connect/disconnect during emission > and recursive emission allowed. This can make it very hard for > the user to know when a given slot is guaranteed to be never > called again (i.e. to be able to delete an instance a method of > which was used as a callback). > > What will be the strategy for the standard in this regard? > > 4) Given all the things above but also more generally, I found myself > wishing several times, that there would be a means in the signal > interface to connect a slot for at most one emission, i.e. the > signal disconnects the slot automatically after it was called once. > Would you consider this to be a useful convenience? > > > TIA, > > aa > > -- > Andreas Ames | Programmer | Comergo GmbH | > Voice: +49 69 7505 3213 | andreas . ames AT comergo . com
Hey, I'm just a random subscriber here... as for the naming... source/sink would be nicely generic... event source and event sink... *shrug*, just my 2 cents _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list