Comments on signals versus vfuncs

[Owen Taylor <otaylor redhat com>]

* The original GTK+ code (circa 1997) did have signals for
  basically all virtual functions. This resulted in some
  very odd signals. GtkContainer::check-resize, say.

  We justified this by saying "making all virtual functions
  signals allows modifying behavior without derivation"
  but that was a bit of a flimsy excuse. And it is 
  very hard to maintain compatibility when people are
  overriding all sorts of internal virtual functions
  in unexpected ways.

  More recently, the rule has been that signals are added
  only when we want notification in the API. (And when
  the notification isn't better expressed via notification
  of a property change.)

* Making a virtual function a signal is an extremely 
  expensive way of letting a language binding hook the
  virtual function. Because every time the virtual function
  is called in a C (or C++) program you pay all the
  expense of demarshaling and marshaling the arguments,
  setting up the signal, etc. This makes the virtual 
  function call *thousands* of times more expensive.

  It would certainly be possible to use the facilities
  in GObject to provide demarshaling to GValues without
  making everybody pay the penalty, though I'll let
  people figure out the details for themselves.

  One problem is that not all virtual functions are
  expressible in the type system ... look at, say,
  GtkCellRenderer::get_size().

Regards,
  				Owen