3 ms·
For me it’s actually the opposite. I dislike the container/heap functions for the fact that Push() and Pop() try to pass through values in the first place. Esp
by EdSchouten 3y ago
For me it’s actually the opposite. I dislike the container/heap functions for the fact that Push() and Pop() try to pass through values in the first place.
Especially for Pop() it’s completely gratuitous. It’s fairly common that you want to peek at the min-element prior to popping. For example, a work queue might only want to pop jobs if their scheduling time exceeds the current wall time. In that case you already need to inspect x[0] by hand. And if you do that, you simply don’t use Pop()’s return value.
I would rather see that the ‘any’ arguments/return values are removed entirely, and that the caller is responsible for reading/writing them from/to the array directly. It’s sufficient for container/heap to just implement the heapify algorithms. Its interface could just be identical to sort.Interface.
Even though some people hate it, I think it’s beautiful that sort.Sort() is implemented in such a way that it’s oblivious of the underlying data structure and element type, I wish container/heap adhered to the same principle.
- jen20 3y agoThe advent of generics should enable better container structures - whether they’ll hit the standard library is a different matter I suppose. For a heap, something like this seems fine? https://pkg.go.dev/github.com/fufuok/utils/generic/heap#section-readme https://pkg.go.dev/github.com/fufuok/utils/generic/heap#sect... (Hi, Ed!)