Re: [gtkmm] retype() and retype_return()

[Carl Nygard <cjnygard fast net>]

On Thu, 2002-07-25 at 12:36, Murray Cumming wrote:
> On Thu, 2002-07-25 at 16:07, Carl Nygard wrote:
> > On Thu, 2002-07-25 at 09:40, Murray Cumming wrote:
> > > No. People don't understand libsigc++ so they don't contribute to it.
> > > Drastic action is needed to fix that. I expect that people will be less
> > > daunted by a smaller set of code.
> > > 
> > 

First, excuse me for being pedantic... no offense meant, just clarity.

> > No, it's not the library that is hard to understand, 
> 
> You're telling me that you understand all of the generated code? Why
> haven't I received patches adding comments that explain it?

Been busy.  You never asked.  And I never claimed to understand it all,
except that what I looked at didn't seem all that complicated. 


> 
> > it's the m4 macros
> > that generate the many templates that make it daunting.
> 
> True, but we have no solution for that.

Right.  And is chopping them out a realistic solution?  The m4 problem
remains.

> 
> >  You're
> > proposing to remove binders that already work, one of which I
> > contributed because I thought the functionality was incomplete.
> 
> What functionality do you mean? Bear in mind that I intend to keep some
> kind of hide_return() and bind_return() functionality.

You haven't mentioned that before.  What exactly do you mean by "some
kind"?

> 
> >  You're
> > proposing to return the library to an incomplete state.
> 
> It will not be incomplete as far as gtkmm is concerned.

I thought sigc was a separate library?  You're claiming that gtkmm is
driving sigc development, while I was always under the impression that
sigc got split precisely because people used the functionality *outside*
of gtkmm, for other purposes.  You're changing the focus of sigc.

> 
> > So at the very least, I'll maintain what I contributed.  Just keep it in
> > the library.
> 
> Maintain extra stuff in a separate library. Do you need it that much?
> That's the test.

Why would you want to move code that is integrally dependent on sigc
internals and macros into a separate library?  To maintain the separate
library, you're going to depend on the sigc m4 macros to generate the
code, which I believe you have decided to eliminate by packaging only
the generated code in the sigc distribution (I could be wrong...).  If
this is the case, are you going to maintain a developers package so that
the extras maintainer can generate the extras package?

And you're probably going to introduce lag between release of the sigc
and extras packages, right?

Seems more complicated to me.  But if you can make it simple...

Regards,
Carl