Re: Raising the abstraction level



tiggr@gerbil.org (Pieter Schoenmakers) writes:

> Reference counting is an ad hoc surrogate for garbage collection.

Technically, I completely agree with everything you say.

It would indeed be more perfect to gather the reference counting
apparatus into a unified interface, gtk_ref/gtk_unref say.

The question now is, is this worthwhile?  Reference counting for
GtkObjects is sufficiently simple, I think.  Unifying all Gdk ref
counting functions into gdk_ref/gdk_unref should not be too
complicated and indeed be the right thing.  Someone needs to do it,
tho.  But I'm not sure whether a completely unified scheme across
glib/gdk/gtk would buy us much.

> The gtk_widget_ref however does not offer any extra functionality,
> and should be deleted.

It is meant to save you a few casts, just for cosmetic reasons.  A bit
dubious, agreed.  gtk_widget_ref will always be the same as
gtk_object_ref.

>    I'm sure other language bindings do it differently.
> 
> They can't.  They must invoke the proper underlying functions.  Or is
> there something underlying the C interface to Gtk that I previously wasn't
> aware of :-)

Of course these language bindings must use the underlying functions of
Gdk/Gtk but they can present a higher-level abstraction to the
programmer that uses these language bindings.  For example, Scheme has
a real garbage collector, and of course, the Scheme bindings to Gtk
only do reference counting internally.  When you program in Scheme you
do not need to worry about ref counting.  Perl should be pretty much
the same.

I don't think we should try to solve fundamental language problems
from within the Gtk+ toolkit.  C does not have proper garbage
collection, so Gtk+ should not try to offer it (by implementing a
sophisticated conservative GC, say).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]