Re: Proposal: changes to _interp functions

[Owen Taylor <owt1 cornell edu>]

[ my proposal ]

> >   gint
> >   gtk_timeout_add_full (guint32            interval,
> >                         GtkFunction        function,
> >                         GtkCallbackMarshal marshal,
> >                         gpointer           data,
> >                         GtkDestroyNotify   destroy);
> > 
> > And specify that 'function' is ignored if 'marshal' is
> > given. Marius actually proposed a variant on this where 
> > both 'function' and 'marshal_func' have meanings (see below).
> > I tend to think that that is an unnecessary complication.

[ Tim's proposal ]

> now what i'm suggesting is to have two different interfaces:
> 
> gint
> gtk_timeout_add_notify (guint32        interval,
>                         GtkFunction    function,
>                         gpointer       data,
>                         GtkDestroyNotify notify);
> gint
> gtk_timeout_add_notify_marshal (guint32            interval,
>                                 GtkCallbackMarshal function,
>                                 gpointer           data,
>                                 GtkDestroyNotify   notify);
> internaly we cast the "GtkCallbackMarshal function" argument to an
> ordinary function pointer for storage, and keep a flag that describes
> what signature will be used for the invokation.
> 
> i even think this approach will be more consistent with the rest
> of the toolkit, e.g. take a look at gtk_signal_connect,
> gtk_signal_connect_after, gtk_signal_connect_object and
> gtk_signal_connect_object_after (and gtk_signal_connect_interp), they are
> all front ends for gtk_signal_connect_by_type which takes a variety of
> flags to determine the actual behaviour.

If we took this literally. There would be 16 different connect
functions:

(after/not after) x (object/not object) x (marshal/not marshal) x 
    (notify/not notify)

But actually gtk_signal_connect_interp takes an 'after' flag.
(There is no gtk_signal_connect_object_interp, because connect_object
is not really needed in languages with closures). I tend to see
the various variants as "convenience functions" - they make the
common operations easy.

But I don't really see having all sorts of variants of every
function that takes a callback in the library.

  gdk_input_add
  gtk_timeout_add
  gtk_selection_handler_add
  gtk_signal_connect_*
  gtk_menu_popup
  ...

That is hard to document and hard to maintain. I would rather
stick to just two variants for each function - a simple one
that will normally suffice for C, and a _full one that exposes
the complete set of options. (Keeping all the old ones 
for gtk_signal_connect is OK too)

Perhaps I am bit prejudiced against Tim's idea by the names
'gtk_timeout_add_notify' doesn't sound like what it does.
If someone can propse something better, perhaps I could
be won over. ;-)  But what do other people think?

                                        Owen