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/
