Re: Garbage Collection and other things (belated)

[Owen Taylor <otaylor gtk org>]

attila@stalphonsos.com writes:

> On 18 Apr, Daniel Solaz wrote:
> > Guillaume Laurent wrote:
> >>Integrating the Boehm GC in GTK is definitely something worth
> >>considering (at the very least),
> > If GTK gets a real garbage collector, that is good. But I don't believe
> > a garbage collector should be part of a graphics library that pretends
> > to be small and portable.
> 
> My point in the post I made originally was that gtk seems to be slowly
> evolving an object model, and a generic object model implemented in C
> designed to integrate with lots of other languages, even OO ones,
> involves, at some point, garbage collection.  I've built one of these.
> It's possible.  It's nice.  It works.  It's hard.  It may or may not
> be what the gtk developers want to do, but dealing with extensiblity
> without a reasonable underlying object model will quickly get
> unmanageable.  My subsidiary point was that reference counts are not
> as good a thing as people think they are.  They really don't work all
> that well, and end up costing more than other schemes, as unintuitive
> as that sounds.  Lots of people have thought about all of this before,
> and it would serve gtk well if its designers looked into what has
> gone before prior to making all of the same mistakes that everyone else
> has.
> 
> I would venture to suggest that the object layer in gtk should probably
> be split out eventually.  This would put it "below" gtk.  You can do
> this in such a way that M3 or Eiffel or C++ or whatever can be dealt
> with sanely, I think.  

That is a fairly strong claim. Of course, M3 _or_ Eiffel _or_ C++ can
be dealt with sanely. But can M3 _and_ Eiffel _and_ C++ be dealt
with sanely? (At least more sanely then the current GTK+ scheme?)

> Or, this may be too ambitious.  I don't know what the gtk designers
> have in mind.  I also don't understand how this may or may not
> relate to things like Gnome.

Some people are indeed interested in splitting out the GtkObject part
of GTK+. Not in relation to GNOME (the objects there are meant to be
more large scale), but for various other projects.

Even so, GTK (and presumably a split out object system) is meant to be
useable in the context of larger programs which are not written using
GTK+ objects. For all its downsides, reference counting has the
advantage that it can be used in a fairly non-intrusive manner. More
ambitious garbage collection schemes seem to require a large amount of
cooperation from the entire process.

> > Since I'm trying to find out how to solve the interaction between GTK's
> > sort-of-GC and Modula-3's real-GC, I'd like that this 'integration' was
> > done *on top* of GTK, so when non-C-languages are around one can choose
> > how to manage memory: if I have a native GC that is tracking my m3
> > objects, it would be nice if it could track GTK's objects as well.
> 
> Except that if you've got widgets written in guile or perl or Objective
> C that you're using, then it may not be so good.  There are combinations
> that just won't be possible, of course... again, the ambitions of the
> gtk folks in this area aren't known to me, but given the strategy
> they've taken towards making gtk useable from a variety of languages,
> it seems like they must be thinking about multi-lingual widget sets
> at some point. Or not.  I can see either point of view being argued for
> ("less filling!... great taste!..." etc.).

Multilingualism is certainly an important goal for GTK. But
I'm still quite skeptical that any sort of GC in GTK can solve
all the problems when it has to interact with the GC's in other
languages.

Regards,
                                        Owen