Re: libsigc++2 in gtkmm-2.4? (was: Re: [gtkmm] ANNOUNCE: glibmm 2 .3.0)

[Martin Schulze <martin-ml hippogriff de>]

Am 2003.10.18 14:27 schrieb(en) Chris Vine:
> On Wednesday 15 October 2003 8:18 am, Murray Cumming Comneon com
> wrote:
> > From: martin-ml hippogriff de [mailto:martin-ml hippogriff de]
> > > Well first of all sorry for answering this late.
> > > As to changing back to "SigC::Slot" in libsigc++2 I must say
> > > that I would really prefer a compatibility header:
> >
> > Yes, that would be OK if it can be done. We would have
> > #ifndef LIBSIGC_DISABLE_DEPRECATED
> > Around the API.
>
> Changing the API by going from initial upper case letters for
> namespace names
> to lower case letters seems to me to be a self-indulgence which should
> be
> resisted (but I have no expectation that my view will have any effect,
> given
> previous exchanges of view on other API breakage issues).
>
> However, if initial capitals for namespaces causes aesthetic problems
> for the
> maintainer why not just use a namespace alias, so allowing either to
> be used
> without having to mess around with configure time definitions:
>
> namespace sigc = SigC;
>
> in the relevant header files.
>
> Of course this will not work if it is also proposed to change all type
> names
> forming part of the public interface to initial lower capitals, but
> that
> could be dealt with by using the equivalent typedefs and thus avoid
> breaking
> code.

I think you don't really understand the situation. libsigc++2 has been
rewritten from scratch. The idea was not to do some minor improvements
to the library but to get the maximum out of c++ and to do it "the
right way", i.e. code as close to the standard as possible. This has
to do with Karl's initial plans to try and get libsigc++ into boost. 1)

The result is that there are some substantial differences in the API
(implicit type conversions, unnumbered signal/slot templates,
accumulators instead of Marshallers, slot iterators, more powerful
adapters, etc.).
This doesn't mean that libsigc++2 cannot be made API compatible to
libsigc++-1.2 but IMO it is much wiser to do this in a compitibility 
header than to put this burden on libsigc++2 itself. However, such a
compatibility header is only possible when it uses its own namespace.
I have no intention to break the signal/slot API for gtkmm users until
at least gtkmm-3.0.

Regards,

  Martin


P.S.:

1) The reason why this never happened is that the boost people don't
use m4 to produce human-readable files but insist on their c
preprocessor magic. Also their own signal/slot library has dependencies 
to other boost stuff in the core parts which would be unacceptable for
libsigc++ users since boost as a whole is too big a dependency.