Re: [Vala] Implicit lamdas/closures

["Christian Hergert" <christian hergert gmail com>]

I absolutely love the yield idea, very python-twisted'ish.  Lets make sure the yield can return a value as well so we can have the following:

var value = yield obj.do_something ();

-- Christian

On Tue, Sep 16, 2008 at 3:34 PM, Jürg Billeter <j bitron ch> wrote:

On Tue, 2008-09-16 at 22:48 +0100, Sam Liddicott wrote:
> Here I am working my self into brain fever, and not a peep!
>
> No-one says "stop him, the fool" or "darn fiendish cunning" or even
> "he's using goto's, the churlish knave".
>
> No-ones saying "don't taint the language with your base practicalities"
> or even "whatever can it mean?"
>
> Someone say something before I get dragged back to more fiscally
> accountable projects.
>
> If I write the code is it likely to be accepted?

I like the idea of adding language support for asynchronous method
calls, I was thinking of implementing this for some months but it wasn't
on the top of my todo list.

I haven't tried implementing this, but I think that the Vala code could
be made even simpler and the labels should not be necessary. My idea is
to introduce a modifier/attribute to mark methods as async capable. If
you call an async method using the `yield' keyword, it will
automatically introduce a continuation point there, i.e., add a callback
and return in C. The async method call will not accept any delegate or
lambda, it will just implicitly use the rest of the method body.

In contrast to your example, it should support the two situations (async
or sync call) without the if (request.may_async) in the Vala code, it
already has all the information necessary. It should probably generate
two public functions in C, an async and a sync version, similar to the
GIO API.

Does this make sense or do you need an example? Do you see any issues
with this approach?

Jürg

_______________________________________________
Vala-list mailing list
Vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list