Hi Jiří,
On Sat, 2009-09-12 at 00:27 +0200, Jiří Zárevúcky wrote:
> I did some thinking on the subject of asynchronous (aka "yielding")
> methods. I'd like to share and discuss some of my ideas here.
>
> --------------------------------------------------------------
> 1. "yields" keyword is far from intuitive
> --------------------------------------------------------------
>
> [...]
>
> Personally, I would find following much more appropriate:
>
> public virtual async void method (int arg) throws IOError;
I agree with you here. The reason I've chosen `yields' is that I've
initially thought that the same syntax could be used for more generic
coroutine support. However, the focus was always on asynchronous methods
and there is no plan to integrate generic coroutine with the same syntax
anymore.
As async support is still considered experimental, I think it makes
sense to change the keyword now. I don't know whether we should use
`async' or rather the unabbreviated `asynchronous' to be clear, although
it's quite long. Any opinions?
> --------------------------------------------------------
> 2. purely asynchronous methods
> --------------------------------------------------------
>
> There are actions that can't be represented synchronously and methods
> where synchronous variant needs to be written separately. 'nuff said.
> This could perhaps be handled using specialized [Async] attribute with
> appropriate parameters.
For this exact reason - and the fact that sometimes parameter lists
differ slightly between sync and async variants -, I'm actually tending
to drop the combined sync/async method support, and only support purely
asynchronous methods. While combined methods sound interesting, they are
not essential, and I prefer a solid slightly simpler async support to
advanced async support with issues.
> -----------------------------------------------------------------------
> 3. stopping execution until a callback yields
> -----------------------------------------------------------------------
>
> There are actions that can be described as "waiting for callback". For
> that to work correctly, programmer needs to make sure all the connected
> callbacks are disconnected as the method returns. If there is mechanism
> to "pause execution" (from the programmers POV) until some connected
> callback yields, it would allow doing this cleanup in a finally block.
> I have a faint feeling that bare "yield" keyword already has some
> semantics, but for the sake of demonstration:
>
> public int method () yields throws Error{
> try {
> signal1.connect ((x) => yield return x;);
> signal2.connect ((x) => yield throw new Error ("Error
> occured: %s", x);); // the first one to be executed decides the return
> condition
>
> yield; // wait and treat yields as if they were called here
> }
> finally {
> signal1.disconnect ();
> signal2.disconnect ();
> }
> }
>
> This is also a prime example of method that can't be translated into a
> synchronous version.
>
> -------------------------------------------
> 4. co-execution operator
> -------------------------------------------
>
> [...]
This is an interesting idea. However, I hope you understand that it
doesn't make sense to me to closely look into things like that until
basic async support is working well - and Vala 1.0 has been released.
Jürg
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
