Re: [Vala] [Async] why use .begin ?

[JM <interflug1 gmx net>]

Hello
What does .end() do? Are there any examples available?
Please also put some information to the tutorial. That would be great!
Thanks
Jörn

> No, the call without .begin() is being deprecated.
>
> > From yestarday's discussion on IRC I understood it's not generally possible
> to collapse to synchronous call automagically. Doing it involves running
> a (recursive) main loop until the callback is called, but this brings a lot
> of problems like something quitting the outer loop, the nested loops being
> quit out of order and such. Therefore it should not be done without user's
> explicit request.
>
> The reason for .begin() is mostly a symetry with .end() and code readability
> where the use of .begin() clearly indicates that asynchronous operation is
> being started (and will continue beyond the statement).
>
> > Right now async has a related problem though for async methods that return 
> > values, i.e. the following code:
> >
> > ================
> > async int func()
> > {
> >         return 10;
> > }
> >
> > void main()
> > {
> >         int i = func();
> > }
> > ================
> >
> > leads to the -- somewhat surprising -- error message:
> >
> > ================
> > mickey andromeda:/local/pkg/vala/test$ valac --pkg gio-2.0 foo.vala
> > foo.vala:8.10-8.15: error: invocation of void method not allowed as expression
> >     int i = func();
> >             ^^^^^^
> > ================
> >
> > since internally the invocation is moved to func.begin(), which is (always) a 
> > void method. This is no problem from async to async as we would be using int i 
> > = yield func() in that case, however it's quite common to call async() from 
> > sync(), hence some additional work is required here.
>
> There are two ways to call asynchronous method from synchronous one. You may
> want to just start the operation and register a callback for it or you may
> want to wait in a new instance of main loop until the operation completes.
> The bare func() would be somewhat ambiguous in this respect and so it's being
> deprecated.
>
> There may eventually be some construct to call asynchronous operation
> synchronously, but it is unlikely to be a simple call.