Some counterpoints: * In the question of "Channels vs. Callbacks", the best choice is "neither". Write a blocking API with a fixed number of items and a Scanner-like Iterator for an unknown number of items. * It requires spawning a Goroutine even if none is necessary * It adds syntactic overhead to the caller even if none is necessary * If the caller in any way wants to customize the channel (e.g. add buffering) they have to spawn yet another Goroutine * It requires specifying how the API behaves if the channel isn't read/quickly enough/whether it needs to be drained or not/when it will be drained - while an io.Closer already is the common idiom for resources to be closed
> > - Internals of the API might be affected by unknown behavior of > callbacks > > Like what? A panic should just crash the program, no affected behavior. The package providing the API shouldn't have to worry about it. Anything else is isomorphic to unknown behavior of the channel consumer. That being said, again, the correct choice is neither, which also doesn't suffer any of these problems. Encapsulate the concurrency. > > - lets the consumer decides how many goroutines is needed to handle it > > Just like a Scanner-like iterator. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
