Re: [gtk-list] Re: Garbage Collection and other things (belated)

[attila stalphonsos com]

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.  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.

> 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.).

Pax,
	:: S.