On Sun, 2008-10-19 at 18:30 +0100, Sam Liddicott wrote: > [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. > I don't quite get your point. At least I don't agree 'this' should track the lambda vars. They are unrelated. the lambda vars(if I correctly understood you, by lambda vars you are referring to the local variables of the function that creates the lambda function) has something to do with the 'runtime context', ie 'scope' of the lambda function(and as well as any function), and should be part of the 'closure', as the MDC article implies.
Functions in vala are not objects. They are not ref_counted and they have no internal data members; just like what their correspondents in C. But if we plan to do something like function-in-function and scoping, eg, connecting signals with function-in-function, we have to create a closure, whose 'scope' member is set to the 'local' of the running parent function. Later on when the closure is no longer in use, it is unrefed, disposed, and the 'scope' member is destroyed. It is quite possible to do it within the GLib framework if a GClosure can be used in place of the callback, eg, signal handlers and g_source. A GClosure can be created for the lambda, with the 'scope' variable as the user_data, and a function to unref the 'scope' is provided as a callback. Then we connect to the signal with the closure. when the signal is disconnected, (most likely because of the disposal of the object), the user_data of the closure is destroyed. BTW, there is an erudite description on closures (about javascript) at MDC: http://developer.mozilla.org/en/A_re-introduction_to_JavaScript#Closures > 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 <[EMAIL PROTECTED]> > Sent: 19 October 2008 15:40 > To: Sam Liddicott <[EMAIL PROTECTED]> > Cc: Ali Sabil <[EMAIL PROTECTED]>; Christian Hergert > <[EMAIL PROTECTED]>; 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 <[EMAIL PROTECTED]> > > Sent: 19 October 2008 11:31 > > To: Christian Hergert <[EMAIL PROTECTED]> > > 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 > > <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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] _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
