<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 20, 2015 at 4:57 PM, roger peppe <span dir="ltr"><<a href="mailto:rogpeppe@gmail.com" target="_blank">rogpeppe@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's somewhat harder with the uniter, because its very state-dependent<br>
channel operations make it awkward to write a uniform outer select loop.<br>
<br>
If I were to do it, off the top of my head, I might consider making uniter.Mode<br>
(which BTW should not really be exported) into an interface and each of the<br>
existing mode functions into a separate types.<br></blockquote><div><br></div><div>Yeah; oddly enough, it was partly my imagining going in more-or-less that direction (but implementing the modes in another package) that led to them being written as exported.</div><div><br></div><div>However, I think the mode approach has outlived its usefulness. After a couple of years, Modes are now either trivial or bloated; in ModeAbide in particular, there are too many possible inputs and reactions to keep track of them in one select loop. And it's becoming increasingly inconvenient to depend on the golang scheduler; and, basically, we need an operation queue that self-prioritises/compacts as events come in.</div><div><br></div><div>It won't be trivial -- in particular, we need to disentangle the local-state storage from the operations that currently generate it -- but the queue can be synchronous; it can be composed of smaller queues that manage priority of closely-related hooks (as relation hooks are implemented today); and it can actually be unit-tested in adequate detail. And the event delivery might still not be beautiful, but I'm pretty sure we can do better than the existing Filter if we don't constrain ourselves by optimizing the interface for delivering events to mode loops.</div><div><br></div><div>Cheers</div><div>William</div></div></div></div>