On Fri, 2009-04-03 at 11:07 +0200, Hans Meine wrote:
> I take the opportunity to say thanks for your explanation and the good docs;
> I
> always found them quite clear.
Ah, well I'm happy they were helpful.
> However:
> > [...] if you design your application to use signals and
> > callbacks from the start, coroutines don't really fit in very well.
> > Think of coroutines as an alternative approach to a sequence of signals
> > and callbacks.
>
> This is a very important statement which seems to be the reason why I always
> had the feeling that kaa contains great stuff, but I found it hard to find
> spots for use in my own programs.
Fair enough. I've added some similar wording to the documentation.
> Later, you wrote:
> > But to drive the point home, I should also provide the code that does
> > the same thing only _without_ a coroutine, by using callbacks and
> > connecting to each step: [...]
>
> This is a great example! Be sure to include that in the docs.
Done, as you later saw.
> Maybe one could even add an example with a mixed approach, which could help
> the transition very much. ("Now I have started my project already, with lots
> of callbacks, I guess it's too late to integrate coroutines!")
This is tricky. If one had used _specifically_ kaa.Signal objects to
implement signal/callbacks, then it's possible to merge the two
approaches, because kaa.Signal objects can behave as InProgress objects
and therefore can be yielded from a coroutine (and entry resumes when
the signal emits).
But if you're using kaa.Signal objects that much, then you're using kaa
as the foundation for your application, and in that case you're probably
already using coroutines, especially because a lot of the supporting
classes in kaa (like kaa.Process, kaa.Socket, kaa.rpc) naturally
encourage the use of coroutines (because it is often awkward not to use
them).
In Duncan's case, kaa came along much later, well after a framework had
already been established. In this case, as Duncan is finding, it's much
more difficult to bolt coroutines on. Because:
1. coroutines require the use of the kaa mainloop (notifier) -- but
I guess Duncan has switched over to the kaa mainloop now?
2. the caller of a coroutine must understand that it's a coroutine,
which makes them unsuitable for use as standard callback
functions where the caller just expects a standard callable that
will return some value.
So basically the only way I can see to integrate coroutines into an
existing project is to start using them only for fairly new core
functionality of the application -- that is, something that doesn't have
much interaction with other areas of the application, which probably
expect more traditional callbacks.
Maybe dischi has some ideas?
Jason.
------------------------------------------------------------------------------
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
