[Galago-devel] Libsoylent API

Ikke eikke at eikke.com
Mon Jun 20 12:03:04 EEST 2005


On Mon, 2005-06-20 at 10:48 +0300, Kalle Vahlman wrote:
> On 6/19/05, Travis Reitter <treitter-dev at netdrain.com> wrote:
> > Here's my current line of thinking for the Libsoylent API.
> > 
> > We have a major choice between restricting the calling programs' access
> > to accessor ("get" someone's metadata) and mutator ("set"), constructor
> > (create a new person), and deconstructor [?] (delete a person)
> > functions, giving the caller an ID for each person; or actually
> > returning a SoylentPerson struct and letting the caller modify and
> > access people metadata there.
> > 
> > The first approach is more restrictive and would be slower (though it
> > probably wouldn't be significant), but would cleanly abstract some
> > details from the caller (for instance, a set function would directly
> > make evolution-data-server modify the existing database). The second
> > approach would require some synchronization (after modifying a
> > SoylentPerson struct, the caller would need to use a function to save
> > the changes to the database(s)).
> 
> If the library is in C, then the C API is probably best to be
> get/set-based. Any language bindings that have proper support for
> objects could then implement object-y API with those (which can detect
> errors on set/get or something like that).
> 
> It would sound a little too error prone to let the user modify a
> struct directly in C, and would result in a messy error detection
> code.
Agree 100%
Not using get/set methods (if we allow -set ;)) would result in a
completely unusable mess, not able to write bindings for other
languages,...
If we'd go for GObjects (would we? IMHO its a great system) we're almost
forced to use -get/-set, and creating bindings to Python, Mono and maybe
other platforms/languages I'm not familiar with should be very easy.

Ikke




More information about the galago-devel mailing list