Re: [PATCH] (u)int64 + string value transforms

[Andy Wingo <wingo pobox com>]

On Thu, 07 Feb 2002, Tim Janik wrote:
> On Wed, 6 Feb 2002, Andy Wingo wrote:

> the int64 part looks ok, but we're not going to support string->integer/float
> conversions.

ok.

> there's a lengthy thread on the reasons for that in the list archives, but
> basically, it's that we're not going to force a specific syntax on people,
> and that we're not able to handle derived types correctly. so please back out
> that part and resend the patch (sending it to me privately on the second round
> will suffice to get commit aproval).

ok. couldn't find the thread, but understood more or less, i think
(ie, no support in glib unless it can be supported properly).

> as an aside, the ->string conversions shouldn't really be used in production
> code, they are more of a convenience variant for debugging purposes and could
> possibly change.

i wouldn't have bothered replying to the list were it not for this part
:) in gstreamer we need to serialize objects to xml. right now i'm using
g_strdup_value_contents() to stringify props, and i was wanting to add
the inverse operation. that's fine if all i have to do is register a few
more type transforms, but my question is whether i should actually
register the ->string transforms within gstreamer itself so that we can
guarantee that they are there and so they work properly, or whether we
can rely on glib to have these routines availiable. so, i reckon i'll
include the stringification into gstreamer too.

the point that "they could change" would be mitigated if
destringify(stringify(foo)) could be assured to be equal to foo by glib.
but if this is not the case, and my string-> routines are not wanted
in glib, please note the debugging nature of the standard string value
transforms in the docs, when they get written.

thanks much, and a revised patch is coming,

wingo.