Re: G_TYPE_<unterminated-string> (was: Re: Status of 2.0 API freeze bugs)
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: G_TYPE_<unterminated-string> (was: Re: Status of 2.0 API freeze bugs)
- Date: Tue, 3 Apr 2001 18:32:37 +0200 (CEST)
On 3 Apr 2001, Owen Taylor wrote:
> > 2) the argument order, which is (guint8 *bytes, guint n_bytes) in your
> > patch
> >
> > for (1), i need to extend glib-genmarshal.c to generically deal with in value
> > types that get passed as multiple args (marshalling of out value types with multiple
> > args are not going to be supported for 2.0).
> >
> > for (2), we definitely need to change that to (guint n_bytes, guint8 *bytes),
> > and people have to be aware of this as these args are passed through a varargs
> > interface.
> >
> > on why the number of elements should be passed as first arg by general
> > convention:
>
> The _general_ convention on the position of "number of items" is not
> as important to me as the specific convention on strings w. length.
>
> g_strndup, g_strncasecmp, g_convert, g_locale_to_utf8,
> g_string_insert_len, g_unicode_strlen, gtk_text_insert,
> gtk_editable_insert_text...
well, for g_strndup() it's probably not hard to see why the length
argument got appended with gchar* g_strdup (gchar *str); already being
in place. g_strncasecmp() is another example of 2 strings + 1 length,
additionally it got modelled after strncmp() which i can see taking
precedence for glib.
> (And of course, ::insert_text, the signal for which we wanted
> G_TYPE_BYTES to begin with)
>
> At least 20-30 more
>
> Now, you may argue that a lot of this (though not nearly all of this)
> is new API. But in any case, there is darn lot of this in this
> order and I don't see changing it now, even if I was convinced
> that it was right to do so.
>
> The only exception to the uniform ordering I know of is gtk_widget_path
> and friends, and that is sort of odd for other reasons because the
> length refers to two strings.
i think we should better ask whether it's a good idea in the first place
to reverse the (n_elements, elements) scheme for strings in gtk+, and then
technically, G_TYPE_BYTES is not something storing strings per-se.
it'd be a pity to have G_TYPE_BYTES and G_TYPE_CHARACTERS when they
only differ in the order they expected their length and contents args.
>
> Regards,
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]