I am happy to see (so far) nobody has issues with the pattern as it exists currently - except for naming. *Request sounds good to me, but the reason currently we use *Options is that it is similar (and thus supposedly easier for users) to existing user code. It might be more confusing for jclouds developers though...
In order to keep this thread going (and also if you want some more reading on this), I just added a blog post to the website. Most of it is related. It mostly targets new contributors, though. http://jclouds.apache.org/blog/2014/09/03/better-builders/ ________________________________________ From: Andrew Gaul [g...@apache.org] Sent: Wednesday, September 03, 2014 9:49 AM To: dev@jclouds.apache.org Subject: Re: Using *Options for domain objects? I also prefer the builder pattern for options. A lot of older code have mutable options, with the NONE constant actually allowing mutations! On Wed, Sep 03, 2014 at 09:36:19AM +0100, Ignasi Barrera wrote: > I also like the syntax and think that's a pattern we could use in more > places. > > Regarding the naming I'm +1 to change the *Options to *Request or something > else to avoid confusion with the already xisting Options pattern. > El 03/09/2014 02:53, "Andrew Phillips" <aphill...@qrmedia.com> escribió: > > > Reviewing a couple of PRs [1, 2], I noticed a pattern for creating > > subclasses for domain objects that need different attributes depending on > > whether they should be created or updated. > > > > An example looks like > > > > SecurityGroup.createOptions().name("jclouds-test").description("jclouds > > test security group").build()) > > > > which seems like nice syntax to me. It's implemented by having a > > "CreateOptions extends SecurityGroup" domain object subclass, whose Builder > > is returned by createOptions(). > > > > I added some comments to the PR because the main usage of classes named > > *Options that I'm aware of in jclouds is as a parameter object to modify an > > API call, not as a *domain* object variant. > > > > I'm a bit late to the party here, so apologies if I've missed a discussion > > on this topic. I was wondering if this new naming risks confusing users, > > and was curious to see if anyone has any suggestions... > > > > Regards > > > > ap > > > > [1] https://github.com/jclouds/jclouds-labs-openstack/pull/135 > > [2] https://github.com/jclouds/jclouds-labs-openstack/pull/132 > > -- Andrew Gaul http://gaul.org/
