[gnome-db] Re: GdaRow as a GObject
- From: "Murray Cumming" <murrayc murrayc com>
- To: "Vivien Malerba" <vmalerba gmail com>
- Cc: gnome-db-list gnome org, Murray Cumming <murrayc murrayc com>
- Subject: [gnome-db] Re: GdaRow as a GObject
- Date: Tue, 27 Sep 2005 09:45:45 +0200 (CEST)
> 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).
>> 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.
> Rodrigo, do you think I should correct the few items Murray mantionned
> above before the 2.0 or should I wait after it?
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]