Another suggestion: createBuilder gives you the CreateBuilder which gives you a CreateObject. (replace with update for the other one).
________________________________________ From: Jeremy Daggett [jeremy.dagg...@rackspace.com] Sent: Thursday, September 04, 2014 4:59 PM To: dev@jclouds.apache.org Subject: Re: Using *Options for domain objects? Definitely -1 to ³request²Š ;) I have been spending quite a bit of time on option related classes over the past couple of weeks. From what I have observed, most option classes extend HttpRequestOptions, which is only concerned with headers, queries, and form params. Logically, when I hear the term ³options², to me it means ³here are the options I need to create/update this resource². Then, its not just about headers, queries and form parameters anymore. Either ³CreateTemplate² or ³CreateParams² could work. After getting into OpenStack Heat templates a little more, I might have a differing opinion! heh FWIW, if we change the createOptions()/updateOptions() builders to createWith()/updateWith() instead, it might make a little more sense: Port port = portApi.create(Port.createWith(network.getId()).build()); versus: Port port = portApi.create(Port.createOptions(network.getId()).build()); It flows a little more nicely IMHO! /jd On 9/4/14, 12:58 PM, "Andrew Phillips" <aphill...@qrmedia.com> wrote: >> The new pattern still encapsulates options for creating a resource >> though. The name seems appropriate. To me, createOptions() says >> "build me the options for creating a resource". > >That seems logical, but I'm just thinking in terms of how *Options is >used everywhere else in jclouds: it's an *additional* argument to a >call which modifies the way the response is provided. And it's almost >always accompanied by a version of the call that does not require >options. > >Agreed that *Request probably isn't a good alternative as, if >anything, it's even more overloaded. CreateParams? CreateArgs? >CreateTemplate? > >ap
