Re: [Vala] Proposal for an improved delegate/lambda handling



[My email server ate half my reply! Here's all of it]

That's pretty much where I'd got up to.

I was also trying to use libffi for it's trampoline for data-less callbacks.

For glib callbacks if the data pointer is not weak (I guess it always is weak) then the lamba vars can ref counted, otherwise then the lamda struct could maybe be free'd when "this" is freed at least, meaning the object will track it's lamba var instances.

Maybe the lambda vars should be fields of an implicit subclass of a lambda object to help manage this. Maybe different lambda base classes could be specified depending on the situation.

Currently in the samba C code the caller explicitly frees the lambda struct (of course) at the end of the callback.

Maybe in the vala code we can avoid using the word "return" except for the final return. This would cover continuation style code, but might not favour signal handler style events, but perhaps they are actually a different case anyway...

Sam


-----Original Message-----
From: Yu Feng <rainwoodman gmail com>
Sent: 19 October 2008 15:40
To: Sam Liddicott <sam liddicott com>
Cc: Ali Sabil <ali sabil gmail com>; Christian Hergert <christian hergert gmail com>; Vala Mailing list <vala-list gnome org>
Subject: Re: [Vala] Proposal for an improved delegate/lambda handling


On Sun, 2008-10-19 at 14:19 +0100, Sam Liddicott wrote:
I like any method that allows the callback block to acess all
variables from the original scope and also allows execution of the
callback to fall-through into the original scope at the end of the
callback block; implying that the whole function must be generated
with labda-style local vars.

It is not easy to do in a (GLib and VALA)-consistent way. There is only
one user_data field in GLib callbacks and it is already used for 'this'.

Although it is possible to reuse this parameter for a 'local' variable,
in which we store every local variable, problems exist.

The lambda-style local vars has to be on the heap rather than the stack
so that it doesn't get immediately destroyed when the parent code block
is no long in execution. But putting local variables in the heap
contradicts with the way C works; therefore the resulted c code has to
be really messy. It is not a big deal anyways since VALA already
generates messy C code in many situations.

More importantly, there seems to be little possibility to free these
lambdas because we don't know when they are no longer in use. Neither
can we disconnect signals because we lost the track of the 'user_data'
parameter if we are out of the function that connects the signal.

The following code shows a possible implementation.

struct has_lambdas_local_type{
int ref_count;
GObject * this;
int local_1;
int local_2;
int par1;
};
void local_unref(gpointer local);
void local_ref(gpoitner local);

void lambda1 (...., struct has_lambdas_local_type * local) {

}
void has_lambdas (GObject * this, int par1) {
struct local_type * local = g_new0(struct local_type, 1); /*inevitably
leaked*/

local_ref(local);
local.this = this;
local.par1 = par1;

...
..
do stuff with local.local_1, local.local_2 and such.
...

local_ref(local);
g_signal_connect(..... , lambda1, local);
local_ref(local);
g_signal_connect(..... , lambda2, local);

....
playing with local.local_1, local.local_2, again.
....

local_unref(local);
return;
}



Yu

Sam



______________________________________________________________________
From: Ali Sabil <ali sabil gmail com>
Sent: 19 October 2008 11:31
To: Christian Hergert <christian hergert gmail com>
Cc: Vala Mailing list <vala-list gnome org>
Subject: Re: [Vala] Proposal for an improved delegate/lambda handling

Here is another set of proposed syntaxes, so that the post_request()
looks like this:

client.post_request("GET ...") {
    debug ("Got Response: %s", response);
} {
    debug ("Got error: %s", error);
}


Another possible syntax would be:

client.post_request("GET ...") {
    (response) => {
        debug ("Got response %s", response);
    }
}


which in the case of a callback+errback would look like:

client.post_request("GET ...") {
    (response) => {
        debug ("Got Response %s", response)
    }
    (error) => {
        debug ("Got error %s", error);
    }
}


This 2nd syntax is actually inspired from Scala. Scala supports
currying, as well as optional parentheses for parameter passing,and
the ability to substitute parentheses for curly brackets in some
place. This set of feature combined together allow building methods
and functions that look and feel like control structure. (At least
that's what I understood during a short trip to the Scala world).

Thanks for all your feedback.

--
Ali


On Sun, Oct 19, 2008 at 2:00 AM, Christian Hergert
<christian hergert gmail com> wrote:
        I like it. Might get confusing if someone wanted to mix direct
        delegates and anonymous ones though.
-- Christian On Sat, Oct 18, 2008 at 4:14 PM, Yu Feng
        <rainwoodman gmail com> wrote:
        > On Sat, 2008-10-18 at 22:57 +0200, Ali Sabil wrote:
        >> Hi all,
        >>
        >> I would like to start a discussion about a small syntactic
        sugar
        >> addition to Vala, that would in my opinion slightly improve
        the
        >> situation with asynchronous code. The following code sample
        should be
        >> self explanatory about my proposal:
        >>
        >> delegate bool HttpResponseCallback (string response);
        >>
        >> public class HttpClient : Object {
        >>     public void post_request (string request,
        HttpResponseCallback cb)
        >> {
        >>         cb ("Hello world");
        >>     }
        >> }
        >>
        >> // Current State
        >> var client = new HttpClient ();
        >> client.post_request("GET ....",  (response) => {
        >>         debug ("got response %s", response);
        >>         return true;
        >>     }
        >> );
        >>

[The entire original message is not included]
_

[The entire original message is not included]



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