On Thu, Oct 25, 2018 at 1:53 PM Eric S. Raymond <[email protected]> wrote:
>
> robert engels <[email protected]>:
> > Wouldn’t you normally pass a consumer or collector function into the
> > interator code? Then you only write the iterator once, and it is hidden.
>
> I'll look into that approach. There might be a readability issue there.
You can extend that to implement something similar to Java streams, like:
type Stream func() (Item,bool)
func (s Stream) Filter(predicate func(Item) bool) Stream {...}
func (s Stream) ForEach(f func(Item) bool) {...}
func Iterator([]Item) Stream {...}
Iterator(bigArray).
Filter(func(item Item) bool {
...
}).
ForEach(func(item Item) bool {
...
})
You could probably come up with different Iterator() functions if you
have multiple ways of iterating through your data structure.
>
> > Similar to how the sync.Map.Range() works.
> >
> > Barring that, I don’t see how
> >
> > for(i:=c.Iterator();i.HasNext();) {
> > v := i.Next()
> > }
> >
> > is that much more difficult to use - especially since you state it is a
> > custom iteration anyway?
>
> I don't like the eyeball friction.
>
> I write for long timescales. Someone other than me will have to be able to
> maintain this code someday.
> --
> <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be your
> own.
>
>
> --
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
