Java client API

Russell Brown russell.brown at me.com
Wed Mar 23 19:04:53 EDT 2011


Hi Jon, 
A replied to Kresten, and before I managed you replied more succinctly with a lot of what I had to say.

On 23 Mar 2011, at 21:25, Jon Brisbin wrote:

> I personally don't like using ambiguous short names. I get that you can technically distinguish things by package name but using a simple name that is very common isn't good for code readability. "RiakEntry" is unambiguous, self-documenting, and semantically correct. "Entry" would, in my mind, represent a very generic interface that defined various kinds of "Entry"s of things.
Agree.

>> Perhaps, for this very reason, store() should be an operation *directly on the RiakEntry*; and then guide people by the way these are obtained.
> 
> This feels like a Grails GORM convention. Using finders and calling save directly on the object you're working with. I guess it's more a matter of personal preference, but I'm not sure I like it as a general rule. It's not a very object-oriented approach, either, as it mixes concerns a little too much, in my mind.
Agree.

> 
>>     RiakClient renamed to Riak
>>     RiakObject renamed to Entry
> 
> IMHO the name "Riak" for a client doesn't feel semantically correct to me. Its also a little ambiguous. It's a Riak what? "Riak" the noun refers to the server, not a client which can connect to it.
> 
> While I don't agree with dropping the Riak part of RiakEntry, I do think the name "entry" is consistently used in the Riak docs and should be carried over rather than use the more ambiguous term "Object".
Agree.

> 
>>     Bucket b = c.get("people");
> 
> Again there's the issue of mixing concerns. Does the helper class describe a resource or operate on the resource? In this case it does both. Just not sure everyone feels the same about compressing these together. Dynamic language fans might like this approach because it's results in less "stuff" overall to keep track of. OO folks, though, might not feel comfortable with that paradigm.

I don't agree. An entry is in a bucket, from where else would you get it? The client as well, for convenience, but a bucket is nice abstraction that riak provides directly. In riak it is just a namespace (with properties) but you can't access a key without it.

> Whichever approach you end up choosing someone's going to hate anyway and tell you you should have picked the other one. ;)

Agree. Joshua Bloch's bumper stickers say "You can't please everyone so aim to displease everyone equally." and in this case I'd like to do the minimum possible workable abstraction so that those suitably pissed off can at least bless us all with an alternative that is easy to adapt to existing code.



> 
> Truth be told, I'm not a die-hard OO fan. I'd rather use Erlang or Haskell if I could! 
> 
> 
> Thanks!
> 
> Jon Brisbin
> 
> http://jbrisbin.com
> Twitter: @j_brisbin
> 
> 
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110323/171ae894/attachment.html>


More information about the riak-users mailing list