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();

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!


/jd

Reply via email to