Guile-gobject just got GOOPSier

[Andy Wingo]

Hey folks,

I've been working on making subclassing, property definition, and signal
definition work in a more GOOPSy way:

 - It used to be that you couldn't subclass a <gtype-class> with the
   standard define-class syntax, but now you can.

 - #:instance slot allocations for <gtype-instance> descendants now set
   object properties on the primitive <%gtype-instance> SMOB, not the
   GOOPS wrapper. This is important because there can be many
   <gtype-instance>'s for one C object, but only one <%gtype-instance>.

 - You can expose slots as gobject properties by passing a #:param-spec
   option when you make the slot. See tic-tac-toe.scm for details.

 - You can define signals when you create a new class by passing any
   number of #:signal options to the class definition. Again, see
   tic-tac-toe.scm.

 - gtype->class is a lot simpler, internally; the complexity was
   offloaded to the <gtype-class> initializer.

With all these changes, the need for the (ugly) let-params and
define-gobject-class macros is gone. I guess when I made them I was
really looking to create a python-like block structure for class
definitions, but now that I realize (reading the GOOPS manual *again*)
that encapsulation is orthogonal to OOP I feel better about the
flat-level syntax. But opinions are welcome, of course; that's why I
send all these emails...

And now with all of this, I think guile-gobject finally has a better
syntax than PyGtk, if for nothing else that we don't have to explicitly
register the type, and we don't need to chain up in the object
initializer.

Just the latest news from Namibia,

Andy