What makes this one a little different and noteworthy, is that AnyEvent claims not to be an event system as such, but rather a compatibility layer on top of event systems. I have so far resisted writing this particular loop implementation on the grounds that, since AnyEvent just applies a cross-compatibility layer on top of some other existing event system anyway, IO::Async might as well use that underlying event system directly. In practice however this doesn't quite seem to work out all the time; existing code exists and is already written. Sometimes that existing code already works using AnyEvent directly, making it harder to drop a small section of IO::Async-based code inside it.
In that situation, an individual module/function/etc.. can construct itself an IO::Async::Loop::AnyEvent, to allow that component to use IO::Async-based functionallity, while still interacting correctly with the rest of the AnyEvent-based program.
It is not primarily intended that this module be used as the basis of an entire program; mostly because a neater solution for mixed IO::Async+AnyEvent exists in the form of AnyEvent::Impl::IOAsync.
There are still some minor issues to deal with currently; most notably that because each of IO::Async and AnyEvent could use the other as an event source, there are some circularity problems when AnyEvent picks AnyEvent::Impl::IOAsync to use, when IO::Async::Loop::AnyEvent loads it.
Deep recursion on subroutine "AnyEvent::Impl::IOAsync::io" at /home/leo/src/perl/IO-Async-Loop-AnyEvent/blib/lib/IO/Async/Loop/AnyEvent.pm line 103.Hmmmmm.... A little work there still needed :)
But why is none of this in your POD? :)
ReplyDeleteI don't know. -Should- it be in the POD? Seems a slightly odd thing to write about in the docs themselves, don't you think? Besides, the circularity bug is now fixed at least.
ReplyDeleteNot all of it, naturally, but it does not seem odd at all to me to give a quick idea of what purpose the module was intended for. To you it might be quite obvious that AnyEvent::Impl::IOAsync is what you probably want if you’re starting on a new application: you understand the exact relationships of the modules after all. For someone who does not come at this from your perspective, who is just looking for tools to fulfil a need, it may not be clear at all.
ReplyDelete“When would I use this” is something only documentation can answer (and at the same it's what a novice most needs to understand), whereas “how do I use this” can be gleaned even from the code itself if need be. The what is comparatively easy; it’s the why that is important to record. (This is much the same rule as when writing comments.)
So yeah, I think you should waste a few words on this in the POD. :)
Well, that depends in part on how much the preference to use one module or the other really matters, and how much strength one actually places in the opinions given above.
ReplyDeleteThe more I think about it, the more I don't really know myself which way around ought to be considered neater. Both work, pretty much identically, so in fact I'm not really sure any more whether the advice written above even ought to remain standing.
This in part is why I wrote it in a "throwaway" blog post, rather than actually inline in the real module documentation. It's not really a hard fact, just a momentary thought, subject to me changing my mind again.
OK.
ReplyDelete