Re: [gnome-db] GdaValue sustitution for GValue

[Murray Cumming <murrayc murrayc com>]

On Wed, 2006-03-29 at 16:38 -0600, Daniel Espinosa wrote:
> 
> 
> 2006/3/29, Murray Cumming <murrayc murrayc com>:
>         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
murrayc murrayc com
www.murrayc.com
www.openismus.com