Re: [Vala] Fail to generate C code for following vala code, is this a bug?

On Sat, Mar 27, 2010 at 12:17 AM, Julian Andres Klode <jak jak-linux org> wrote:
On Fri, Mar 26, 2010 at 11:56:04PM +0800, PCMan wrote:
Thanks for the fast reply.

On Fri, Mar 26, 2010 at 6:45 PM, Julian Andres Klode <jak jak-linux org> wrote:
On Fri, Mar 26, 2010 at 11:07:20AM +0800, PCMan wrote:
Hi list,
I tried to use Vala for the first time and the following code failed
to generate correct C code.
Is this a bug of vala or what's wrong with my code? (code is attached
to the end of this mail)
You define *_finish which is already defined by making the standard
functions async. Read

But Vala should probably report an error if one creates an async
function "f" and a function "f_finish"; instead of creating invalid
The problem is, if I only override f, vala complains about abstract
method f_finish is not implemented. If I override f_finish, too, then
this results in duplicated method definition since another one is
automatically generated by vala async mechanism. So, it's not possible
to implement a interface like GVolume in vala. If this is not the
desired behavior, then it should be a bug. If this can be done in
vala, that can be quite useful. I'm trying to imiplement a new
GVolumeMonitor for gio based on some dbus services. Since vala has
amazing dbus support, it's the best tool I can think of for this job.
It's a pity that I encountered this error.

Well, than f_finish() should probably not be there in the Volume
interface; so I think that's a bug.
So how can I fix this? Ship with a custom glib vapi file and remove
*_finish from GVolume? Will this work? Or, can you make automatic
generation of *_finish optional in Vala, or make the automatically
generated *_finish override the abstract method in parent interface if
its found?

For the second question, if I want to return a unowned GList, it has
to be owned by the class and cannot be a local variable, right? Would
you please add this to vala tutorial? I found it not documented and
this behavior is not easy to figure out. In addition, this is not
consistent with GObject with C. In C we can create a new GList and
return it without the need to make it owned by anyone. The callee of
the function is responsible to free the list.

Because the list is unowned in can not be local, as it would go
away once the function returns. If you want to return a locally
created object, the return value can only be owned.
This is quite different from C and C++ and is hard to understand for a
C programmer I think.
However, I don't get it. Let take GVolumeMonitor::get_volumes as  example.
It returns unowned GLib.List. So if I want to implement that, I should
create a list and make it owned by the object instance and then return
it unowned. However this is slightly different from the behavior of
glib in C. In C GVolumeMonitor::get_volumes returns a
"newly-allocated" GList containing a list of GObjects. The caller is
responsible to g_list_foreach(list, g_object_unref, NULL); and then
However, with Vala, how can I make vala methods return a "newly
allocated GList" with all objects in it having increased ref_count?
Automatic ref couting management in Vala is handy if you only use it
in Vala but I find it difficult to make things right when interfacing
with C code. I need to check the generated C code to see if it does
what I really want. Any better guide for this? Already read Vala
tutorial, but I still haven't get it.

Thanks in advance.
For example, IMO this should be supported.
public unowned GLib.List<GLib.Object> get_list() {
    var list = new GLib.List<GLib.Object>();
   // Do something to append items to the list
    return list; // transfer the ownership to callee
If you transfer the ownership, the list will be owned
by the caller. And then the list can not be unowned;
as the ownership of the unowned list is kept.
Julian Andres Klode  - Debian Developer, Ubuntu Member

See and

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]