So while debugging the last bug that was reported on this list, I came across something I really don't like about the getMaxDistance, getHamiltonianDistance, and getHexagonalDistance functions in SparseGrid2D and SparseGrid3D.
SparseGrid is different from other grids in that it has essentially *three* modes:
It's the "Unbounded" part that's a problem for me. These three functions take a "toroidal" parameter which lets you do wrap-around collection of locations or objects up to a certain distance away from a central point. But what if the "toroidal" parameter is turned off? It turns out that SparseGrid collects neighbor cells and objects as if it were *bounded*.
Bounded makes sense if you want to be consistent with collections made in other grids (ObjectGrid2D for example). But it makes it _impossible_ to do unbounded collection.
I'm going to make a some new versions of these functions which take a "bounded" parameter and a "toroidal" parameter. If toroidal=true, then bounded must = true (it'll throw an exception if not). Otherwise bounded can be true or false.
The question is how to define the older functions that don't have a "bounded" parameter. Do I:
1. Define them as assuming bounded <- toroidal, that is, if it's not toroidal, it's unbounded. This is the behavior used in Continuous2D and I think it makes much more sense as a default for a potentially infinite grid.
2. Define them as assuming bounded <- true. This is the behavior _assumed_ in the documentation of Grid2D. It would make the results returned by SparseGrid2D always consistent with those of other grids even if it's infinite (the out-of-bounds values would simply be ignored).
The question is: which is least surprise? My inclination is #1. People assuming boundedness will be surprised by extra values that show up in their results *if* for some reason they accidentally had placed objects outside the bounds. BUT if we did #2, then people assuming unboundedness would have results not show up at all, and that'd be bad.
What do you think?