* Ali Sabil wrote, On 15/07/08 10:47: > > > 2008/7/15 Sam Liddicott <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > * Jared Moore wrote, On 15/07/08 10:40: >> >>> And in the advanced example: >>> http://live.gnome.org/Vala/AdvancedSample >>> >>> >>> what does the s signify in >>> >>> this.foo += s => { >>> stdout.printf ("Lambda expression %s!\n", name); >>> }; >>> >>> >> 's' is the formal parameter of the function, just like s and p are >> formal parameters in the first example. You could put parentheses >> around it if you like, but you don't need to because in that case >> there's only one parameter. >> > Thanks. > > In that example do you know what s signifies? - The signal foo > doesn't seem to take any parameters. > > > Hi, > > Signal handler always have the "signal sender" as 1st parameter, in > this case it would be the AdvancedSample instance from which the "foo" > signal originated. > > I proposed the "sender" keyword inside signal handler context (just > like the "this" keyword inside the object instance context) to > eliminate this confusing parameter a while ago, but it didn't seem > like a good idea for many people. Hmmm... this makes me feel uncomfortable in the same way the glade example callbacks make me feel uncomfortable, there seem to be implicit parameters which are not defined in the prototypes, you just have to "know", the s was not referenced in the foo signal declaration either.
Is this a case of glib not leaking enough information to vala? It sounds like a bug to me. Is this anonymous signal handler invoked as a flat function or method? Does "this" have a value (I guess it does or the use of name would fail) in which case, surely s must be declared somewhere else... Sam
_______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
