[boost] Re: Re: Proposal for Boost.Signals order of slots

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-09-19 16:45:36

Douglas Gregor wrote:
> On Thursday 18 September 2003 07:58 pm, Edward Diener wrote:
>> On the second issue: I acknowledge this at the bottom of my original
>> post. Ideally it would be nice for the end-user to know that a
>> particular connection refers to a particular handler. I am used to
>> Borland's __closure where the member function handler can actually
>> have its __closure address taken and compared against the actual
>> address in the __closure pointer which represents the signal. Of
>> course this is a simpler, less flexible system that does not do
>> multi-cast events.
>
> Well, you're not the only one that wants this capability :) Herb
> Sutter wrote an article on function, and that was his main
> criticism/suggestion.

Yes, I read it. I was also under the impression that some work was being
done to distinguish boost::functions but maybe I heard it wrong.

>
>> If the boost::function, boost::bind concept will never allow the
>> end-user to know what handler is actually bound to a boost::function
>> after the fact, then the idea of user-defined ordering, where the
>> two const boost::function references are passed at decision-making
>> time, is worthless.
>
> I don't know that boost::function ever will allow this... it's not
> technically feasible in C++98/03, but who knows what will change in
> the next revision of the language.
>
>> OTOH, your suggestion above makes me think that a user-defined
>> ordering might be at least conceivable if the lexigraphic function I
>> originally described actually passed back to the end-user the group
>> type values instead of const boost::function references. The group
>> type values could also have, as an example, C++ member function
>> pointers which would enable the end-user to determine which slot
>> should be called first.
>
> Yes, that could work.

In that case having a fifo, lifo, or userdefined for the ifo parameter below
might be worthwhile.

>
>>> The benefit of allowing both LIFO and FIFO ordering is that users
>>> get more control over slot ordering. There may be uses where this is
>>> absolutely necessary; I'm not sure.
>>
>> From you perspective is it really difficult programming ? It seems
>> that once you have a FIFO queue for a given group, going backward
>> through that queue is easy.
>
> I'm not at all concerned about the implementation side... once FIFO is
> implemented, LIFO is trivial. It just means that one inserts at the
> beginning of a list instead of at the end.

Exactly. That is why I would support lifo. The implementation should not
complicate anything too much.

>
>>> The cost is that we will need more connect() overloads, and we'll
>>> have some duplication in the slot interface: you can order slots via
>>> group names and with fifo/lifo subgroup ordering. One could argue
>>> that this completely redundant, because one can use a pair<group,
>>> foo> instead of group slot ordering to achieve the same thing.
>>>
>>> Here's a counter-proposal, that I think captures most of the
>>> semantics of your proposal. I'll note differences at the end:
>>> 1) Connecting a slot without specifying a group name uses a
>>> default-constructed group name.
>>
>> Group "value" instead of group "name" ? Name implies to me that you
>> are specifying the group value as a literal.
>
> Yes, perhaps that's better nomenclature.
>
>>> 3) "user" in-group ordering doesn't exist (because I don't think
>>> it's feasible from an implementation perspective)
>>
>>  But the
>> first time some programmer asks why he can't make the final decision
>> just before the signal occurs, we can both smile.
>
> :)
>
>>> 4) "lifo" ordering doesn't exist, because I'm guessing it isn't work
>>> the addition of more connect() overloads. This is the change for
>>> which I have the least rationale.
>>
>> I agree with you on a practical level since I have never used a
>> system, other than your current implementation, where fifo wasn't
>> the rule. I do wonder if anyone has ever used a system where the
>> last slot connected is the first to be signalled. It does seem to me
>> that the overhead for this is merely a very slightly more
>> complicated and less elegant interface.
>
> My concern is only the complication of the interface. Every new
> overload brings additional complexity. We now have:
>
> connect(group, slot)
> connect(slot)
>
> We're definitely adding:
>
> connect(front_or_back, slot)
>
> If we add the ability to use LIFO or FIFO, we add three more
> overloads:
>
> connect(group, slot, ifo)
> connect(slot, ifo)
> connect(front_or_back, slot, ifo)

These latter should be the only calls, with ifo defaulting to fifo if the
user doesn't specify anything.

Essentially then you have added one more connect for front_or_back and added
another parameter at the end.

I tend to overdesign but that is my personality, and the one benefit of it
is anticipating some initially odd things which some user or other actually
wants. I admit that I am not bothered by overhead as long as the end-users
who do not use the additional feature(s) are not penalized speed-wise. But
you should choose as your own vision dictates. Even without lifo or
userdefined, making it easier to specify front_or_back and changing to fifo
should be worthwhile and cleaner than currently.