> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List<String> peerURLs();
> +
> + public abstract List<String> clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List<String>
> peerURLs, List<String> clientURLs) {
@zack-shoylev I think you made the point previously, maybe here or on IRC, that
I agree with in that builders, at least so far as AutoValue classes are
concerned, should be used when those classes are client facing. In this case
the CreateMember class would be just that and so I think it makes sense to
Builderize (?!?) it. Other classes which are not client facing, and are simply
handed back from a function call, need not have this functionality. Maybe this
is obvious but I thought it a point worth making. I'm actually writing up the
builder class now so if we are in agreement I can send in another squashed
commit with the builder functionality added on top. Going forward I will follow
the same model with this provider, that being: client facing value classes will
get builders if only to keep things consistent.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37641771
