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

[Julian Andres Klode <jak jak-linux org>]

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.

> 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.

> 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/.