> > This makes sense, though it's not binary protocol specific. > > The binary protocol has the advantage of managing the creation, > modification, and retrieval of the value abstractly. Ideally, you > wouldn't set the value independently of the incr or decr commands. >
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 just updated the page with a comment. The comment in this case is good, thank you for the clarification. Jason
