On 09/12/2009 01:34 PM, Jürg Billeter wrote:
Hi Jiří,
[...]
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?
'asynchronous' is too long IMO. 'async' is quite obvious, it's used in
other libraries then GIO as well.
--------------------------------------------------------
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.
I don't know about removing altogether. AFAIK it just feeds the normal
codegen with the same data, no big deal. Maybe it would be more
reasonable to disable by default with some attribute for enabling?
-----------------------------------------------------------------------
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.
Sure, the basic support is hardly usable at the moment, so these
features (if accepted) may not be realized for some time. This is just
for the sake of sharing ideas and discussion.
Jürg
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
