Hi there, So this patch has the vala binding and I replaced all "char **" stuff with GStrv, so that the binding tool recognizes it and makes it a " string[]". The .vapi and .gi now also have at least a little bit more correct typing. On Thu, 2008-07-31 at 12:06 +0200, Philip Van Hoof wrote:
On Thu, 2008-07-31 at 11:03 +0200, Philip Van Hoof wrote:Is it ok to add a vala binding in src/libtracker in indexer-split ?By looking at the generated binding, I noticed that the API in tracker.h has a few serious flaws and problems: * It pretends to be GObject-like, but it's really one big facade API for TrackerClient (so the only object that we can make out of it, is TrackerClient). The parser noticed this and decided to make static methods for all instead of building different classes (I can't blame the tool, that's about the only thing you can do with this kind of API). It should probably be like this: class Tracker.Files, class Tracker.Search, class Tracker.Keywords, etc etc. Instances of those classes must solve the "Tracker.Client" and the "Tracker.connect(foo)" stuff themselves internally (why bother the application developer with this anyway?). * Types like "char **" must be GStrv, else any binding tool will see such types as a by-reference passing. You get "out weak string" rather than "array of strings". * There are GPtrArrays being returned. Those will contain arbitrary C pointers, all typing will be lost and no Boxing will automatically take place. Meaning that the language binders must provide all that manually for each and every language binding. Much better would have been to use a collection API instead (http://live.gnome.org/IteratorsAPI). Even if those are always strings, then still by just looking at only the API you can't know. You also don't know who should free those, or what will free them if you don't need to do it. For example, without learning the internals of Tracker, how do I free the results of this one? GPtrArray * tracker_keywords_get_list TrackerClient *client, ServiceType service, GError **error); And "get_list", what does that mean? What will be in there? How will it look? Strings? How do I know for sure? And if it's strings, why not just return a GStrv instead? And why do other APIs that return arrays of strings do return GStrv and others GPtrArray? Right now some APIs are returning "char **". The only reason why I know it's a GStrv-like blob of C memory is because there are sample tools in libtracker that use "g_strfreev (blob_of_c_memory)" on the returned value. It's not even documented in tracker.c as a gtk-doc comment. The typing is not a GStrv, just "char **", which can mean 15 things in C. My opinion: we need to rewrite tracker.h's API and make it all sane.
-- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be
Attachment:
valabinding__and_gstrv_typing.diff
Description: Text Data