Re: glibmm API freeze and vfuncs

[Murray Cumming <murrayc murrayc com>]

On Wed, 2008-02-20 at 14:24 +0100, Marko Anastasov wrote:
> On Wed, Feb 20, 2008 at 1:45 PM, Murray Cumming <murrayc murrayc com> wrote:
> > I think it's time to freeze the glibmm API. Let's say we'll freeze it by
> >  February 24th, 4 days from now. We've gone unpleasantly far past the
> >  usual API freeze date for GNOME, though that's mostly glib's fault for
> >  being late with the API:
> >  http://live.gnome.org/TwoPointTwentyone/
> 
> Ok, it is time and we're as far as I see done with classes and methods.
> I'll make sure I spend some time going through the API again later today.
> 
> >  There are still some vfuncs that are not wrapped. But thinking about it,
> >  I don't see the use of these for us. I don't imagine that anyone would
> >  implement a custom Drive, Volume, File, etc, in C++.
> 
> I agree.
> 
> >  On the other hand,
> >  they are a likely source of refcounting problems. This is an important
> >  decision because we can't add them later without breaking ABI.
> 
> Do you mean that generally half-covered vfuncs can cause refcounting
> problems? Could you explain how, or give some pointers to old threads
> if it's been discussed before?

I mean that vfuncs often have unusual (and undocumented) refcounting
policies, particularly for return values. They can also handle NULL in
odd ways, and respond oddly to the vfunc being NULL or not NULL.

When we get a vfunc wrong then we generally break the entire class for
our wrapper.

> >  I'll probably comment out most of the vfuncs in the next couple of
> >  days.
> 
> Probably the best thing to do here. These are not widgets; using gio
> generally means composition, inheritance meaning extending. If someone
> would like to extend gio, then it should be done in C and perhaps
> discussed as a gvfs module.


-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com
>