These would line up nicely with the newly implemented All, Keys and Values functions in the standard maps package. Adding the two iter.Seq methods also allows for compatibility with slices.Collect.
Unfortunately, Keys() conflicts with the existing pre-iterators method and would require a major version change (or a different name). For the long-term I think the package would benefit from this consistency with the standard library. Also, the current version of the Keys() method can be inefficient on large maps and moving to an iterator by default instead is a good API improvement IMO.
Some other points:
All() would be identical to the current Iterator() method, but again, would be more idiomatic.
Values() was never implemented previously so no problems adding this.
As we currently have ReverseIterator() maybe we should have AllFromFront() and AllFromBack() instead. This is both idiomatic and consistent with the naming in this package. All() could be an alias for AllFromFront().
I understand that a major API change isn't always desirable, but I believe these changes will benefit the design in the long-term. I've created a branch with the proposed changes in my fork.
It would be nice to have the following methods available:
These would line up nicely with the newly implemented
All
,Keys
andValues
functions in the standardmaps
package. Adding the twoiter.Seq
methods also allows for compatibility withslices.Collect
.Unfortunately,
Keys()
conflicts with the existing pre-iterators method and would require a major version change (or a different name). For the long-term I think the package would benefit from this consistency with the standard library. Also, the current version of theKeys()
method can be inefficient on large maps and moving to an iterator by default instead is a good API improvement IMO.Some other points:
All()
would be identical to the currentIterator()
method, but again, would be more idiomatic.Values()
was never implemented previously so no problems adding this.ReverseIterator()
maybe we should haveAllFromFront()
andAllFromBack()
instead. This is both idiomatic and consistent with the naming in this package.All()
could be an alias forAllFromFront()
.I understand that a major API change isn't always desirable, but I believe these changes will benefit the design in the long-term. I've created a branch with the proposed changes in my fork.