Re: [boost] libsigc++ inclusion (was Formal review request: Signals library)

From: Karl Nelson (kenelson_at_[hidden])
Date: 2001-12-28 14:15:37

> At 01:30 AM 12/27/2001, Karl Nelson wrote:
> 
>  >...  Is it
>  >the point of a standards orginization to simply hand down standards which
>  >someone arbitarily feels is best or should it be adapted from those
>  >items which are found in industry to already work well?  I am not saying
>  >fresh code is not needed, but you seem to really be reinventing the 
> wheel.
>  >Considering most of the interface (signals method name, connection
>  >concept) were taken from sigc++ why not adapt the whole thing rahter
>  >than such peice meal.
> 
> While a library "found in industry to already work well" has an obvious 
> head-start, other considerations are also important.
> 
> For instance, someone has to be willing to do the actual work.

I don't think this is really the issue.  If there was a significant
chance of sigc++ making it, I or one of my cohorts would get the work
accomplished.  However, given the ammount of work and the likely hood
of sucess based of resistance to the idea I find I doubt that 
sigc++ is a good candidate.   

There are other and better ways for me to contribute to boost and
the C++ community.  What I do want to do is make sure people
clearly decribe the limitations of what they are proposing here and 
the assumptions they are making.  Also make sure they are looking at
the industry solution and disclosing what things their implementation
fails to do that the industry one is already accomplishing.  

A number of arguments brough as contrast of libsigc++ really haven't
been contrasts at all in that sigc++ could adapt to those.  Like the
marshalling mechanism, that is flexible and if there is a better way
I will happily change.

What it can't adapt to is not having concrete functor types moved 
through the layers.  That is a structural design choice to keep the
code under control.  If I make it take arbitrary types ( like place a
less_than_f<>) then I have to have the code take an unknown and 
undescribed type which not be possible and at the same
time keep "clean error messaging" and "opaque interfaces".  
Since both of those are goals of sigc++ that makes boost and sigc++
pretty much incompatable.  SigC++ is intended for todays compilers
and to be clearly within the range of industry practice. 

I do think the level of meta programming being done in some 
of these boost libraries is a clear indicator that something
in the core language is broken.  If seems where we are trying to
take C++ is outside the designed scope of were templates were 
intended.  SigC++ is outragous enough with ~4000 lines of templates.
(Generated mainly with m4)  The single bind adaptor in boost is 
~2700 lines.  C++ clearly lacks a replacement for "foo(...)" and
it shows.

--Karl