On Tue, 2006-05-16 at 15:09 -0500, Daniel Espinosa wrote: > > > 2006/5/16, Vivien Malerba <[EMAIL PROTECTED]>: > On 5/9/06, Daniel Espinosa <[EMAIL PROTECTED]> 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? > if someone writes a patch, yes, let's send it to glib developers for inclusion in latest glib. -- Rodrigo Moya <[EMAIL PROTECTED]>
_______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
