jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Daggett <jeremy.dagg...@RACKSPACE.COM>
Subject Historical context of *Options.NONE?
Date Wed, 21 May 2014 19:07:45 GMT
Hi devs,

Many of the option classes in jclouds have a "NONE” field that cleverly creates a default
instance of the class containing no options. Can anyone enlighten me on the history of this
pattern and why this is necessary?

My opinion is that an API should have a method without options, and one with options. For
example, in the OpenStack Swift ObjectApi, I now have the following patterns for using options
classes (sans varargs ;) ):


list(ListContainerOptions options);

get(@PathParam("objectName") String objectName);

get(@PathParam("objectName") String objectName, GetOptions options);

put(@PathParam("objectName") String objectName, @BinderParam(SetPayload.class) Payload payload);

put(@PathParam("objectName") String objectName, @BinderParam(SetPayload.class) Payload payload,
PutOptions options)

>From my perspective, there is no reason to keep this field around unless there is a good
reason for it.  Please let me know, thanks!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message