-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guidance/suggestions on Iterators and Stop() #130
Comments
Hello, I think you’re right we could use some clarity around how iterators work and any potential pitfalls. So in an effort to preserve long-standing backwards compatibility there are actually three ways of doing iteration.
I personally recommend Each as I’ve always thought it solves all problems of iterations and doesn’t require messy cleanup at all. To answer your questions:
|
Cool, thanks for the speedy response. I'd be happy to submit a PR with these recommendations if you'd like (assuming my company is MIT-friendly, pretty sure but gotta double check) One last question: if you've fully exhausted an Iterator(), do you still need to |
Calling Stop closes the channel. It’s best practice to do a proper shutdown with things. In the event that the channel is not fully drained Stop will ensure the remaining items are drained. So at an absolute minimum it closes the channel. It’s not the end of the world as the channel would be garbage collected but you would be future proofing the code if for example someone came back in 3 months and changed the code to early return (or break). |
Also, I’d love a PR that clears up docs. =) |
it.Stop()
on an Iterator, what happens, does that possibly cause a memory leak? If so, I'd love to have that explicitly called out in documentation.it.Stop()
in a for-loop, or is it usually good enough to justdefer
it upon iterator creation + usebreak
?The text was updated successfully, but these errors were encountered: