On Mar 4, 8:38 am, Jason Sirota <[email protected]> wrote: > If I understand your meaning, it's unlikely you would first *set *a value > and then later incr/decr it. By extension it also means that would not > likely *get *a counter outside of the return value of incr/decr so the > underlying representation of that number would be always be hidden. In fact > the only thing that was failing was my unit tests when it tried > to independently verify the incr worked correctly via a *get *and not a > real-world example.
I'm not so much saying it's unlikely, but it's certainly unnecessary. In my java client, for example, you could incr and decr with default to start and move the counter. Then you could incr by 0 to get the number *as* a number vs. a regular get that will get the number as text. It's not an uncommon pattern to (add k "0") then (incr k) then (get k) => "1"
