Marshalers [was Re: API freezing ...]

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> >  - Not installing random marshalers from gtkmarshal.h. If you
> >    are using marshalers you need to generate them with
> >    glib-genmarshal, and we should enforce that.
> 
>         This of course being a painful change that will require a
> re-release of nearly everything that uses Gtk+ :-) also - it seems
> somewhat strange not to re-use these ( relatively large ) marshalers, or
> is the 'random' the key here ?

The gtk-devel-list list mails I sent on this go into detail but
essentially:

 * The idea would be to publically provide (deprecated) exactly the
   marshalers that we provided in GTK+-1.2. We have 90% or so
   compatibility breakage with GTK+-1.2 in this area currently.

 * The marshalers aren't actually that big ... all marshalers
   included with GTK+ currently are 13k. Most of these
   marshalers are not going to be very reusable:
   gtk_marshal_VOID__UINT_OBJECT_UINT_FLAGS_FLAGS just doesn't
   come up that often. (And 

 * We have a mechanism for reusing marshalers - add them to
   gmarshal.list in GObject ... then:

    - They are known about by glib-genmarshal and it uses
      #defines for them, so you don't have 

    - Everybody can use them, not just projects depending on GTK+
 
 * Export our marshalers is a minor API maintainence disaster:

    - We can never remove a marshaller, even if it is used
      currently only in a deprecated widget; this means
      we can't garbage collect our marshalers. We already
      have junk unused marshalers in gtkmarshal.list currently.

    - If we have to add a new marshaller for (say) an action
      signal we add for a new keybinding, then that ends
      up as part of the public API. 

 * I don't think it is doing anybody favors to have a _random_
   set of marshalers exported by GTK+. If you need custom
   marshalers, you shouldn't have to think about what library
   you depend on might already need that marshaler.

The real fix here would be to depend on a libffi equivalent and
allow NULL for marshalers; except for a few things like
GObject::notify, GtkObject::destroy, I doubt the speed difference
would matter at all. Something for some day in the future...

Regards,
                                        Owen