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
>
