[gnome-db] Re: GdaRow as a GObject

[Vivien Malerba <vmalerba gmail com>]

2005/9/27, Murray Cumming <murrayc murrayc com>:
>
> > 2005/9/27, Murray Cumming <murrayc murrayc com>:
> >> On Mon, 2005-09-26 at 09:36 +0200, Vivien Malerba wrote:
> >> > > > -> if a user wants to update a complete row, create a new GdaRow
> >> > > > object or copy an existing one, call gda_data_model_update_row()
> >> and
> >> > > > then g_object_unref (row)
> >>
> >> So, now I see that GdaRow has been changed to a GObject too.
> >>
> >> The const on the row parameter on
> >> gda_data_model_update_row() and gda_data_model_remove_row() seems wrong,
> >> because they can invalidate/delete the row, though that's not documented
> >
> > You're right; I'll remove them.
> >
> >> for both. I'd also like the documentation for those functions to clearly
> >> state how the row object might be obtained, in order to call these
> >> functions.
> >
> > Yes, I'll update the documentation to make that point very clear.
> >
> >>
> >> More importantly, gda_row_new() and gda_row_new_from_list should do
> >> nothing more than call g_object_new(), because language bindings can not
> >> all call the specific _new functions.
> >
> > It's almost the case, but as the gda_row__new*() functions have
> > parameters like the number of columns in the row or its values, there
> > is a bit more code and that can't be avoided.
>
> This would normally be achieved with properties.
>
> If you absolutely can't do it (and I'm unlikely to find time) then an
> extra gda_row_construct*(GdaRow*, theparameters) function (called from
> gda_row_new*()) is an ugly workaround for now. We could then also call
> that construct function after calling g_object_new(), instead of
> copy/pasting all of the code (which we can't always do because it accesses
> private API).

I'll add properties then:
- "model" for the GdaDataModel (G_PARAM_READABLE|G_PARAM_WRITABLE)
- "values" to set the initial values (G_PARAM_CONSTRUCT_ONLY)
- "nb_values" to set the number of columns in the row (G_PARAM_CONSTRUCT_ONLY)

>
> >> These seem like useful changes that will simplify the API, and I'm
> >> really grateful for your hard work on it. However, API freeze seems a
> >> bit far off at the moment.
> >
> > Yes. I tried to make the corrections (which I believe were required
> > before the 2.0 release) and modifying the API as few as possible. I
> > plan to do more after the 2.0 release.
>
> You can do API deprecations and additions after the 2.0 release, but it
> would be madness to change API after a 2.0 release.
>

I meant in the new dev branch, not in the 2.0 branch.