Re: Consensus on getter conventions?

["Manuel M. T. Chakravarty" <chak cse unsw edu au>]

Maciej Stachowiak <mjs@eazel.com> wrote,

> Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> 
> > Thus don't look to C++ kits for answers.   If fact isn't the concept
> > of returning something which needs to be freed going to be a C concept
> > only.  If you change the name of the function to show this convention
> > then the bindings are going to end up with rather pointless name
> > distinctions.  Why make that distinction for the bindings?  (and
> > using multiple names is going to cause the distinction to be
> > made in the bindings.)
> 
> The bindings could be made aware that this is a naming convention for
> the C world and ignore it.

I don't really understand what you mean by `ignore' the
convention.  The bound functions will end up having
different names while there is no visible semantic
difference between functions with different names.  So, it
would seem in these languages as if the naming were not
consistent. 

> > My personal preference is to have all get_* functions which return
> > something be a pointer to a "static" piece of memory.  Those
> > cases where deallocation is required should return by argument.
> > 
> >   /* this doesn't need to be freed because it was the return */
> >   const gchar* gtk_widget_get_name(GtkWidget*);
> > 
> >   /* this one does need to be free and it is different for that reason */
> >   void gtk_font_selection_dialog_get_font_name(
> >         GtkFontSelectionDialog *fsd,  gchar**);
> >                                       ^^^^^
> >               notice it isn't const because we give it to the user.
> > 
> > This only creates a conflict for the functions which return multiple
> > values which you don't need to free.  (don't know if it helps the 
> > problem.)
> 
> It seems to inflict a fair amount of pain on the C world to make the
> distinction this way. Returns through out arguments are more awkward
> to deal with than ordinary return values.
> 
> I think we should continue with the previous plan, and recommend that
> bindings where the distinction does not matter do an appropriate
> systematic renaming of the funtion names.

This makes it clearer, but renaming functions is not
attractive for a binding, because it means that it becomes
more difficult to use the standard documentation for the
binding.

Manuel