Hi,
Thank you all for the answers. Creating Dova binding for the GObject library is fine, but I would like to narrow my original question. We're planing to create some set of a libraries using Vala and I think that it would be great if we can compile from one source code two libraries for the glib and dova profiles. It's a big waste of time to write code twice for the glib and then again for the dova. For the example take a libgee. Isn't good if we could compile it for dova profile? I suppose there is no very deep dependency from glib.
I'd advice that the core of your system is not dependant on Dova nor
Glib. If you want to use some functionality of the glib or dova
libraries, you just create a wrapper class with two implementations, so
for example:
// common base of glib and dova backend to make sure that they will
// always have the same interface
class AbstractList_PortableImplementation
{
... [some stuff - abstract methods, properties]
}
#if USE_GLIB
class List_PortableImplementation : AbstractList_PortableImplementation
{
protected GLib.List l;
... [other stuff]
}
#else
class List_PortableImplementation : AbstractList_PortableImplementation
{
protected Dova.List l;
... [other stuff]
}
#end
If the core part is big, the gain will be really big. On the other
hand, if you want to write portable code, all the core part must be
using only features of Vala that are a common part of Glib and Dova
features, so no public fields, no signals, etc.
best regards,
If we have some level of abstraction at source code level, may be just a macros support, we could create such libraries.
-- Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na serwerze hkp://keys.gnupg.net My public key with signature 1024D/E12C5A4C is on the server hkp://keys.gnupg.net
Attachment:
signature.asc
Description: PGP signature