AutoBuilder? about auto HOT 9 CLOSED

@ooxi Have a look at the javadoc, there's a new @AutoValue.Builder annotation.

from auto.

This is mentioned in the documentation:

Many users have asked for AutoValue to generate a builder class. We explored this idea deeply. It is much more complex than it seems, especially because field values often need validation. We also feel that, unlike the simple value objects themselves, there is a lot of natural variation in how builders for different types should be written, and it would be a disservice for us to start coercing everything into the same mold.

As a side-note, your sketch can't work because MyValue doesn't have a builder() method, and standard annotation processors can't insert methods into existing classes. Probably if we were to support builders we would generate a public MyValueBuilder class, and you would write

MyValue value = new MyValueBuilder()
    .withFirst("hello")
    .withSecond("world")
.build()

That is in fact essentially what I did in the JavaFX API with another annotation processor. But the objects being built there had public constructors whose parameters defined which properties were required and which could perform any necessary validation. The fit with AutoValue is less good because we don't currently have a way to specify that some properties are optional, and as the text above mentions we also don't have a way to validate them. There's also the question of what the property methods in the builder should be called. withFirst(x)? setFirst(x)? first(x)?

The best approach I can see would be to allow @AutoValue or another annotation to apply to a static factory method (like create in the examples), or perhaps a constructor. The parameters of the method or constructor would then have to correspond to the class's properties, and it could contain validation code. We would probably want another annotation that applies either to the abstract property methods or to the method parameters, specifying that the corresponding property doesn't have to be supplied to the builder, and perhaps also what the default value is then. But as you can see builder generation is already quite a bit more complicated than the simple idea behind @AutoValue classes.

from auto.

Yes you are right that a builder class is generally much more complicated than a value class. My incentive comes from the fact that we had a couple of constructor arguments of the same type and developers constantly did not remember the correct order.

Since you clearly considered adding a builder and for various reasons preferred not to I'm closing this issue.

from auto.

If you are interested in builders you might consider to look at the design of builder generation in Immutables.org project, see http://immutables.github.io/immutable.html#toc6.
You can compare how complex or involving could be to implement this in AutoValue.

from auto.

Looks like this has been just added a few days ago #175

from auto.

@felipecsl Looks great! Is there any documentation on how to use this?

from auto.

Yes, there are a few final improvements and a documentation change in the pipeline and they should show up at the next sync from Google's internal branch. Feel free to experiment; the javadoc should be enough to get the gist.

from auto.

👍 great improvement :)

from auto.

AutoBuilder? Yes! https://github.com/h908714124/auto-builder

from auto.