Re: [gnome-db] GValue and gda_init()
- From: "Daniel Espinosa" <esodan gmail com>
- To: "Vivien Malerba" <vmalerba gmail com>
- Cc: gnome-db-list gnome org
- Subject: Re: [gnome-db] GValue and gda_init()
- Date: Tue, 16 May 2006 15:09:29 -0500
2006/5/16, Vivien Malerba <vmalerba gmail com>:
On 5/9/06, Daniel Espinosa <esodan gmail com> wrote:
> After review the code in gda-value.c, and find a remark about that GLib
> doesn't register functions to transform a Type to a G_TYPE_STRING, I think
> the GDA library *must* register all the functions to transform any type to a
> string in the gda_init().
>
> Now it is done by registering the type in the GType system using the
> gda_*_get_type functions, but for the other like integers, boolean and
> other, I think it's better to be done by gda_init(). An important case is
> GDate, where as a *standar* way, can register a funcition to transform to a
> string, using a string representation, that may, or may not, will meet the
> system's Locale. May is better to let the developer, to desing it's own
> transformation function (or create it in the GDA) to manage the locale
> issue.
I'm not in favor of registering transform functions for GLib types as
it leads to potential modifications of the behaviour of applications
using GValue outside libgda and I'd prefer the registering to be done
by GLib itself. For now, libgda uses some custom transform functions
in the gda-value.c file (which allows to handle the locale as needed).
Vivien
You're
right, but as I sed in a last post, GLib register some transformation
functions and as sed by Basser, actualy is only for a TYPE to STRING,
but not from STRING to TYPE, then I think GDA can register this
*missing* functions with out alter the original GLib implementation
(may be in the future this missing could be part of GLib).
Registering the functions can make a more Object Oriented of the
library, allowing the developer to handle GValues with out worry about
the transformation between TYPEs, and as you sed, GDA *must* register
the custom functions to handle locale and why not some precision issues
in numeric transformation.
What about to include most of this *custom* functions to be included in GLib's next release?
--
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]