Threads for benburkert

  1. 5

    Good article! I wish folks would take it for what it is instead of going off on yes/no generics discussion… The big value in the change here is in the library interface, while the article focuses more on the matching implementation changes. This doesn’t appear to be an article trying to sell generics to the critical internet public (for that, a diff of the public interface should see more focus), it’s a worked example of how coding towards a generic interface works.

    Reading the diff, I was wondering whether there might be a good way to avoid the empty-related parts of the ring buffer. E.g. could you make the buffer work on *T and just check against nil? Or use a type struct { value T, empty bool } internal to the buffer implementation? (am curious now how that would approach would work out concretely with generics)

    1. 4

      Thanks for reading! I think your observation about storing *T vs T in the buffer would work. I avoided the pointer approach here because I assumed at the outset that the buffer would still need to be exposed as part of the API, but (thankfully) that turned out to not be the case. Had it been, creating a pubsub for pointers to a struct S (e.g. PubSub[*S]), which is quite common, would mean the user would have to manipulate a buffer of pointers to pointers to S (e.g. Buffer[**S]) - not good! If/when generics move beyond the prototype phase, I plan to re-examine this package and fiddle around with different layouts for the buffer and cell types to understand how generics impact performance.