GithubHelp home page GithubHelp logo

Comments (4)

deckarep avatar deckarep commented on May 24, 2024

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.

  1. Iter - original method but can leak if the contents of the channel are not fully consumed. ie, an early break or return - at one point this was marked as deprecated and somewhere along the lines it’s been no longer marked that way.
  2. Each - this is just a callback executed per each element to use. You can safely early return, no leaks and no need to close/stop anything.
  3. Iterator - the most recent way - this is an implementation that is more similar to Iterators in the stdlib but does require to call Stop.

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:

  1. When using Iterator you should always call Stop to avoid leaking resources and also provide deterministic cleanup.
  2. Stop should generally be called out of your loop and deferring the call is fine. Remember that defer has function scope, not block scope.

from golang-set.

wittekm avatar wittekm commented on May 24, 2024

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 .Stop() it? If so that's not shown in the iterator example test.

from golang-set.

deckarep avatar deckarep commented on May 24, 2024

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).

from golang-set.

deckarep avatar deckarep commented on May 24, 2024

Also, I’d love a PR that clears up docs. =)

from golang-set.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.