On Wed, 2006-03-29 at 16:38 -0600, Daniel Espinosa wrote: > > > 2006/3/29, Murray Cumming <[EMAIL PROTECTED]>: > On Wed, 2006-03-29 at 11:23 -0600, Daniel Espinosa wrote: > > #define TIMEZONE_INVALID (2*12*60*60) > > An unprefixed/un-namespaced #define like this does not belong > in a > public header. It's namespace pollution. > > > /* Definition of the GType's values used in GdaValue*/ > > > > #define G_VALUE_TYPE_NULL G_TYPE_NONE > [snip] > > I don't think that libgda should be defining things in the G_* > namespace. I don't understand anyway (they are not documented) > why we > need these G_VALUE_TYPE* #defines as well as the > GDA_VALUE_TYPE* enum > values. > > [snip] > > In the 1.2.* series, you found the types of values defined in a enum, > and when I ported to GValue made it with the API compatibility in mind
This new libgda API has so many API breaks that it's not worth confusing the API by doing a little bit of API compatibilit here, I think. > to not modify the code in the providers that use the enum in a switch > function and if you use the #define (SOME_KIND_OF_TYPE) > (gda_get__that_type()) definition, you can't use it in the switch > clause, then you need to re-implement that code (much of work). I don't understand, but OK. > The name of G_VALUE_TYPE* was used to have a diference with the > GDA_VALUE_TYPE* enum; So, the bad name is caused by the need to have the API compatibility? That's even more reason to lose that API compatibility. > in the GdaValue functions you use the G_VALUE_TYPE* to assing a valid > G_TYPE to a GValue, and in some cases use the GDA_VALUE_TYPE to return > or detect the type of G_TYPE in the GValue. > > I think is better to deprecate the use of the GdaValueType, and use > just the GDA_VALUE_TYPE* domain inside the API. Remove, not just deprecate, I'd say. > Otherwise, it looks the same as the existing GdaValue API, > with some > functions removed because they are in the base GValue class. > > I'm trying to don't modify the code a lot, but I think it'll not be > possible becouse to have a API consistent with the GLib one, and not > repeat functions that already exists, need to modify most of code. API compatibility should not be a big worry. It installs in parallel, so people have time to port their code, and there is not much code using libgda anyway. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
