In a perfect world we'd have CellRef be an interface that Cell, MutableCell both match, and then we'd have a hierarchy of containers for each type, where the implementation is on the lowest container that it's possible to have it on. Then for any given container we'd downcast it to the container with the method we needed.
Unfortunately that's very difficult in Go, because a CellSlice, which is a []CellSlice is not equivalent to []CellRefSlice, because there are different methods. And you can't just cast to another, because Go doesn't automatically notice that all of the items in the slice fulfill the other interface.
If we aren't going to do this tiered thing, then ideally we'd rationalize which containers have which methods--right now it's just a random list of whatever was actually used elsewhere in the pacakge.
We could just make all of the methods internal, but some of them really are useful to users of the package...
In a perfect world we'd have CellRef be an interface that Cell, MutableCell both match, and then we'd have a hierarchy of containers for each type, where the implementation is on the lowest container that it's possible to have it on. Then for any given container we'd downcast it to the container with the method we needed.
Unfortunately that's very difficult in Go, because a CellSlice, which is a []CellSlice is not equivalent to []CellRefSlice, because there are different methods. And you can't just cast to another, because Go doesn't automatically notice that all of the items in the slice fulfill the other interface.
If we aren't going to do this tiered thing, then ideally we'd rationalize which containers have which methods--right now it's just a random list of whatever was actually used elsewhere in the pacakge.
We could just make all of the methods internal, but some of them really are useful to users of the package...
297 resolution made this important