look at collapsing/renaming the visual channels #39
Description
Right now there's 3 different visual channels in the public API, which is rather confusing as well as cumbersome:
- continuous
- discrete (point)
- discrete (band)
And that's not yet counting adding any histogram/binning capability to convert a continuous value into a discrete collection, continuous or discrete mechanisms that map values into color ranges, or handling the odd "tick value" complexities of Dates as a continuous or discrete value.
In my ideal world, the public API would just be VisualChannel, but the signatures on the channels themselves make that hard to navigate. Continuous resolves internally to Double, and discrete uses String as a placeholder, but is ultimately more about a collection of hashable entities that can be distinguished from each other.
The computations to make a band from a discrete channel are specific to spacing and depend entirely on the size of the range, but rather feel like its additional complexity in the scales OutputType that I could be moving up the stack, away from Scale itself and having a specific Scale type that returns a Band to a means of computing a band on a discrete scale and not having a separate type.
That, in turn, would collapse the number of types down to two - at which point potentially renaming them as ContinuousChannel and DiscreteChannel might be more than sufficient.
The specific type that I need, and what I do with it, is defined by the Mark that's using the channel - so Bar is currently using this scale that outputs a Band, but I found for labelling the bars, I ended up needing that middle value that would be returned by PointScale as well, which make the whole Band thing feel excessively complicated.