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

[PCMan <pcman tw gmail com>]

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
> > >        http://live.gnome.org/Vala/Tutorial#Asynchronous_Functions
> > >
> > > But Vala should probably report an error if one creates an async
> > > function "f" and a function "f_finish"; instead of creating invalid
> > > code.
> > 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
g_list_free(list);
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 http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.