Re: [gnome-db] libgda-4.0 changes

[Murray Cumming <murrayc murrayc com>]

On Thu, 2008-04-10 at 17:33 -0500, Daniel Espinosa wrote:
> >  They should really be gda_connection_* functions, I think.
> >
> 
> May be, but just point that most of the "Convenient" functions use
> some "primary" parameters like gda_prepare_drop_table that needs a
> GdaConnection object but you can't for now (see bug #525877), use
> gda_perform_drop_table with out before call gda_prepare* function
> becouse its implementation.
> 
> I think that most of this functions could move to other places, but
> the point here is to have all this functions together becouse its
> porpouse is do task quickly and easy as possible. May be we can write
> a section "Gda Easy" in order to describe all this functions and how
> you can take advantage of them, even if they are in diferent parts of
> the documentation.

If you just stick to the regular object-orientated system but make good
documentation (listing important functions in an overview, mentioning
useful functions in function documentation, and having simple examples)
then you won't need a separate set of functions. This is the major
reason why libgda has been hard to use before - not the lack of extra
easy functions. I think we mostly solved that problem with libgdamm's
documentation.

And you won't be forcing language bindings to guess what objects these
functions should be members of, with each binding project making a
different inconsistent decision

On the other hand, most convenience functions in C APIs are for C
programmers only, so you could document them as not for language
bindings and just believe that C coders find their names acceptable.

> GdaHolder have a GValue plus aditional information, then it could be
> called GdaParameter, becouse this will be used as _parameter_ in a
> query.

As it was before. It seemed fine.

> GdaSet holds GdaHolders plus informations about its sources and groups
> of holders for each source, its not just a list of holders and, if I
> understand, you can have one GdaSet to hold groups of parameters for
> different queries. The documentation must be improved to describe this
> "uses" and internal structure. Becouse this Values will be used as
> parameters may be GdaSet couldbe GdaParamenterSet.

That also sounds good.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com