[sigc] Re: perl wrappers for libsigc++2 [was: Re: libsigc++ article]

[Martin Schulze <martin-ml hippogriff de>]

Am 2003.11.08 21:23 schrieb(en) rsteinke w-link net:
> [snip]
>
> > From: Martin Schulze <martin-ml hippogriff de>
> >
> > Am 2003.11.03 16:27 schrieb(en) Murray Cumming:
> > > [snip]
> > >
> > > libsigc++ could distribute the generated .h and .cc files instead,
> if
> > > that would help, and I would accept a patch to do that. For
> instance,
> > > gtkmm distributes generated files.
> >
> > Whether or not we distrubute the generated files, we need to also
> > distribute the .m4 files since people use the macros defined there
> > to generate templates / template specializations for > 7 arguments.
> > Also the perl bindings seem to use our .m4 files.
>
> What the perl wrapper is using is template.macros.m4, to generate
> wrappers
> for Signal0, Signal1, etc. Since the behavior of the macros in this
> file has
> changed between 1.2 and 2.0, exporting it doesn't have the benefit of
> letting
> the perl wrapper support 1.2 and 2.0 simultaneously. I can see two
> fixes for
> this situation:
>
> 1.) Have the perl wrapper grab a copy of template.macros.m4 out of the
> 1.2 tree
> and use that. Since the helper library that uses these macros is LGPL,
> licensing
> issues shouldn't be a concern, and this would allow simultaneous
> support of 1.2
> and 2.0 with some #ifdefs.
>
> 2.) For 2.0 support, change the perl wrapper to wrap sigc::signal
> instead of
> SigC::Signal[0-7]. The perl wrapper would then not need to generate
> multiple
> wrappers for different kinds of signals, and wouldn't need the macros
> at all.
>
> I think I'll probably do 1) at first, and move to 2) at some point to
> allow me
> a chance to examine some of the design decisions in the perl wrapper
> (in particular,
> the wrapper for slot will probably move more to the perl side from the
> C++ side).
> Do we have any idea yet what the C++ API is likely to to in later
> versions (2.2?
> 3.0?) so I can plan around that? In any case, exporting the m4 macros
> files in
> 2.0 won't actually help the perl wrapper.

Later versions could make use of new C++ features that would help to
remove the last hindfoots from the API like the need to specify
a typedef result_type or lacking support for multi-type functors.
This would be 2.2. There are no plans for 3.0 - by that time there
might well be a signal&slot implementation in stl.

Regards,

  Martin