Re: inconsistency in naming functions...



Paolo Molaro wrote:

> On 03/14/00 Antonio Campos wrote:
> > Looking around gtklabel.h, I found that now gtk_label_set is deprecated
> > in favour of gtk_label_set_text, but at the same time gtk_label_get is
> > still being used when it should be gtk_label_get_text for a better
> > naming consistency.
> > So here it is the patch for having both gtk_label_set_text and
> > gtk_label_get_text correctly. At the same time I have moved the
> > compatibility defines:
> >
> > #define gtk_label_set        gtk_label_set_text
> > #define gtk_label_get        gtk_label_get_text
>
> While getting rid sometime of the ugly gtk_label_set/get is fine,
> the signature for gtk_label_get_text should be the saner:
>
> const gchar* gtk_label_get_text (GtkLabel *label);
>
> just as gtk_entry_get_text.
>
> > But when after looking at the code,
> > gtk_label_get_text(GTK_LABEL(label),&my_text) makes my_text point to the
> > label that is in the internal structures of the widget, but doesn't
> > first duplicate the label in the internal structures of the widget and
> > then returns the duplication in my_text.
> > I think this is annoying because is a little inconsistent. Besides that,
> > suppose that the label widget is destroyed. Then you have a pointer in
> > my_text to nowhere, and it's a possible "segmentation fault" problem in
> > the future. (I know nothing about threads, but maybe this is even a
> > better thing when using them).
> >
> > My proprosal is making gtk_label_get_text first duplicate the label that
> > it contains and then returning this duplication to the caller.
> > I think it shouldn't break any code because I have tested the change and
> > GNOME continued to work. Although we should advertise people about
> > possible memory leaks if this change is someday done.
>
> If you need a copy, you make a copy, with the above interface it's as simple
> as:
>
> g_strdup(gtk_label_get_text(label));
>
> lupus
>
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

Good points, but that would break compatibility...



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]