Re: [boost] Formal review request: Signals library

From: Karl Nelson (kenelson_at_[hidden])
Date: 2001-12-26 17:04:24

> With the last update to the Signals library I believe it is now ready for 
> formal review. I believe the interface to be stable, and only minor 
> implementation details should change to accomodate more broken compilers.

I once again fail to see why after my repeated campaigns here in the past
has boost failed to consider that libsigc++ itself might be considered
for boost inclusion.  Instead it seems that near constant replication 
while at the same time missing the features which my users have requested
in the past.  If sigc++ is so good as to get constant replications of
itself why is it never considered a good candidate for standardization
in favor of other options without discussion?

Could some one please explain to me why a large library which the author
has offered to boost at several points continuously is ignored in favor
of NIH (not-invented-here)?

Just for the record (in case no one wants to search the archive), SigC++
1.1 is solely copyrighted by myself.  It is free for all to use 
under LGPL and I will automatically revert the license to public domain
should it ever by included in the stl standard.  It essentially contains
all of the adaptors, binders, and reconnection capablity which users 
need and continues to get more powerful adaptors every month. 
Every discussion of it in this forum seems to revolve around 
"we want a more lightweight solution"  Last debated no one here wanted to 
have the number after the signal or slot class thus I dropped the
issue (and was inlisted in a contract programming and thus have not
been able to participate in boost).  And yet someone is now 
calling for a formal review on something which asside from some minor 
changes is a near copy of my code?  What gives?  

The only discussion I can find for why the current boost::signal
is better is http://groups.yahoo.com/group/boost/message/20412.
And it was not a discussion so much as a statement of one persons
personal preference.  SigC++ 1.1 is in developement and thus if there
were compelling arguments one why or the other things would be fixed.
Further, many of those reasons in the statement are not entirely accurate
as no one has solicited an opinion from the person who would 
knew best.  Several things taken as differences didn't exist.  
For example a signal can be told not to be strict about types by
combining the interface with the retype adaptor, but no one has presented 
any argument that taking strict types is a bad idea.

--Karl