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
