I may not be understanding you correctly, but an interface is a gobject mechanic. This is intended as a quick and simple mechanism for non-gobject library bindings.
Free shouldn't actually be needed, since that's handled by the specified unref_function, but something as simple as: [Compact] [CCode (lower_case_cprefix = "PyObject_", ref_function = "Py_IncRef", ref_function_void = true, unref_function = "Py_DecRef", new_function = "PyObject_Malloc")] public class Object { Like ref_function and unref_function, it's just a drop-in replacement for the memory allocation function Vala would otherwise use which doesn't work with some bindings as they use their own internal memory management. On Thu, Jun 18, 2009 at 4:03 AM, Sam Liddicott <s...@liddicott.com> wrote: > I've given this a lot of thought. > > Here's some ideas: > > A memory management interface which implements these. A class implements > the interface with it's own specific management. > > This would be better done by late binding, the microsoft way, where the > object supports IInterface so it can be queried for a complete memory > management interface. > > As this isn't likely to be magically compatible with what we have now; I > have another solution; based on a tree of memory allocation pools. > > Any allocation of memory (or super allocation) is registered with the > memory pool library. It is then possible to call find_allocation(void* ptr) > and be returned the management interface for that pointer. > > It may be easier if a library will mmap memory it allocates, it become a > matter of checking which range of mmap'd memory the pointer lies between. > > Thus it will be easy to get the memory management interface associated with > a pointer. > > Sam >
_______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list