Remove riakc_map:dirty_value from the Client docs [JIRA: DOC-248]

[unbalancedparentheses]

I am learning how to use data types. I found that the function riakc_map:dirty_value is used in many places on the documentation:
http://docs.basho.com/riak/latest/dev/using/data-types/#Maps

However, if I am not crazy, the function riakc_map:dirty_value has been deleted from the riakc_map:
91e1d60

Do you have any idea if this is normal?

Thanks in advance!

[Vorticity-Flux]

Just stumbled across the same issue. It seems dirty_value/1 was removed from riak-erlang-client as a fix #180

Almost a year later the docs are still out of date. Very frustrating.

[weaktyper]

This issue also snagged me until I found this post.

[nickelization]

Not sure why this GitHub issue was closed, as this is still an issue: the dirty_value function is referred to extensively in the latest docs, but it appears that function longer exists. It was definitely frustrating to me when I was playing around with the Erlang client the other day and ran into this issue.

We could "fix" this by removing the documentation references, but I'm not sure I understand why we had to remove the dirty_value function in the first place. I can see from issue #171 that the dirty_value function was broken at one point, but it seems like it would have been better to fix the function than to remove it entirely.

Maybe there's some reason it would've been extraordinarily difficult to fix it, though? @macintux - could you offer some more insight here? If possible, it might be nice if we could add the dirty_value function back in and fix whatever bugs may have been present.

[macintux]

We chose to not allow Basho client libraries to make their own decisions about the results of operations against CRDTs. Instead, the operation must be pushed to the server for a new value to be obtained.

The alternatives were unpleasant: either allowing the client libraries to disagree amongst themselves (and with the server) about the "real" value (so the result of an operation, at least in terms of the local "dirty" value, would differ depending on whether your application was written in, say, Ruby vs Erlang), or forcing each library to reimplement very complex rules around deletes and other problematic causality edge cases.

[nickelization]

Makes sense. In a perfect world we could port all the necessary code to all the clients so they could all have working dirty_value functions, but I guess we probably have higher priorities to worry about. Leaving this issue open though until we can get the docs updated.