Re: [boost] Signals review

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-02-21 21:36:00

[If I don't explicitly reply to a point, it means I'm nodding my head in 
agreement]

On Thursday 21 February 2002 08:52 pm, you wrote:
> I'd strongly prefer to have a scoped_connection class rather than the
> "controlling" family of member functions on a connection. But I may have
> missed some reason that the proposed design is better.

It appears that nobody likes "controlling,", myself included :)
I'm going to toss out everything "controlling" and use 
connection/scoped_connection.

> I think that last_value and visit_each should either be put in some
> suitable library elsewhere in Boost or made private. Since visit_each is
> already in its own top-level header, this is only a documentation issue. In
> the case of last_value, it seems that unusable might also have to be made
> public, and made a primitive in Boost rather than part of the signals
> library.

I agree that at least visit_each should be a top-level header. I still 
haven't seen a use for last_value outside of the Signals library, but we can 
make it top level. I think that 'unusable' still won't need to be made 
public, because according to the last_value documentation the result_type of 
last_value<void> is implementation-defined (but not void).

> The global names from this library, "signal", "slot" and "connection", seem
> broad enough that perhaps they should *all* go within a boost::signals
> namespace. If the names stay at the top level in the boost namespace, then
> I suggest moving the header files up out of the signals directory too, so
> the directory structure matches the identifier structure. While this might
> make some clutter for people trying to look at the Boost directory, it
> makes it much easier to remember what to type when writing include
> statements.

"connection" (and soon "scoped_connection") definately need to be in the 
signals namespace. I'm not as sure about 'signal' and 'slot', because they 
don't seem to have as many uses outside the library. One comment on this: 
might it be confusion if signal is boost::signals::signal and function is 
boost::function, since they are very similar concepts.

> I think that providing combiners for functions returning bool with && and
> || semantics should be considered. The && one can be thought of as "stop on
> first false" and the || one "stop on first true". The || one comes up
> incredibly often in event handling, one of the most common signal handling
> application areas.

Hmmm. Are you referring to actually overloading the '&&' and '||' operators, 
or to combiners such as:

struct stop_on_first_true {
  typedef bool result_type;
  
  template<typename InputIterator>
  bool operator()(InputIterator first, InputIterator last) const
  {
    for (/* no init*/ ; first != last; ++first) {
      if (*first)
        return true;
    }
    return false;  
  }
};

(analagous stop_on_first_false)

?

> Perhaps the interface for finding trackable objects inside Boost.Bind
> should be documented. It's part of the public interface of Boost.Signals,
> in a way, no?

I was hoping that the visit_each documentation would suffice, because that is 
essentially the only link between the libraries. 

        Doug