Raising the abstraction level

[tiggr gerbil org (Pieter Schoenmakers)]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 10 Apr 1998 23:40:17 +0200

   The ref counting stuff is in fact intended to raise the abstraction
   level.  It gives you an abstraction to do proper resource management.

Reference counting is an ad hoc surrogate for garbage collection.
Granted, unified refcounting throughout a lib or program is better than
nothing, but the programmer still has to remember to type xx_ref or
xx_unref.  And when a programmer must be bored with such details, the
abstraction level has not been raised enough.

   The 12 functions aren't different.

I can not invoke just any of the xx_ref functions if I want to ref a
certain object.  That makes them different.  The healthy exception to this
rule is that I can use gtk_object_ref for any widget, even though there
exists a gtk_widget_ref.  The gtk_widget_ref however does not offer any
extra functionality, and should be deleted.

   They all do the same thing, albeit for different types.  There are not
   12 different reference counting schemes in place.

Can you tell the difference?  If I would devise 11 (skip gtk_widget_ref)
different reference counting schemes, and use each one of them for each of
the existing xx_ref and xx_unref functions, nothing would change in the
use of these functions.  So, we might as well have 11 different schemes!
Doesn't sound like good design to do conceptually identical things in 11
different ways within the same library.  And it is plain pitty in a
library like Gtk that does so many things so correct.

   It's just one, but you have to remember that you have to use
   gtk_font_ref for GdkFonts and gdk_pixmap_ref for GdkPixmaps, for
   example.

This is not a good example of a high level of abstraction: I have to type
something different for each different type of object, even though all I
want is `reference the object'.

   This is because it is a C API to Gtk+.

That is no excuse, especially in a library that does a lot of things quite
good for GtkObject and its `subclasses'.  If there was a GdkObject that
was `inherited' by all structures, and the first field was a `klass', and
the second one a `ref_count', this whole issue with 11 refcounting API's
would not exist.

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

   Gtk-- probably has unified access to reference counting by using C++'s
   overloading features.

I haven't looked at Gtk--, but your assumption is only true if all wrapper
classes inherit from some base class for which the xx_ref and xx_unref
methods are declared as virtual member functions.  Since, in that case it
truely does not matter what the actual type of some object is when you
invoke the xx_ref method: the right function will be invoked.  Without
this virtual function (in this base class), you're stuck at where we
begun: if we think we have a pointer to a GtkObject, but it actually is a
GtkWidget, when we invoke the ref function through the pointer, the wrong
function will be invoked.  This means we still have to worry about types.
So much for raising the level of abstraction.  --Tiggr