Re: [Evolution-hackers] ebook api plans for 1.6
- From: Chris Toshok <toshok ximian com>
- To: Michael Meeks <michael ximian com>
- Cc: evolution <evolution-hackers ximian com>
- Subject: Re: [Evolution-hackers] ebook api plans for 1.6
- Date: Wed, 09 Jul 2003 17:58:35 -0700
On Wed, 2003-07-09 at 06:10, Michael Meeks wrote:
> Hi Chris,
>
> On Wed, 2003-07-09 at 03:21, Chris Toshok wrote:
> > The test-ebook.c file I've attached gives a small example of using the
> > new synchronous api. It iterates over the list of email addresses,
> > which are at present just a list of EVCardAttribute's. Is this way of
> > doing things satisfactory?
>
> It looks nice to me, I can't help feeling that things like:
>
> gpointer get_foo ();
> void set_foo (gpointer);
> Might be better done using the GValueArray thing - which for all it's
> intrinsic clunkiness might give a better result - perhaps with some
> extra boxed types. The contract just seems rather unsafe via a gpointer.
These two functions are just sugar around g_object_set/g_object_get at
the moment.. They don't necessarily need to be there at all, but if they
are I'd like them to remain easier/less typing than g_object_set/get,
not more :)
for instance, this is the body of e_contact_set:
g_object_set (contact,
e_contact_field_name (field_id), value,
NULL);
> > any thoughts? I'm less concerned about getting this right for
> > evolution, since we've already proven we're willing to work with rather
> > broken apis :) I'm more concerned with it being useful for others.
>
> Another thought is; that if this API is going to be ABI stable, it's
> well worth adding gpointer dummy[4+]; to each publicly exposed interface
> - so that virtual methods can be added later.
yeah, definitely. I'll add those tonight.
Chris
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]