Hi Alan,
Thanks for sharing this doc,
On 4/3/19 2:53 PM, Brian Goetz wrote:
Thanks Alan for this good work; grounding the analysis in real codebases is a
valuable tool for validating our theories.
Some comments inline.
One additional thing I would have liked to do is to somehow find classes which
were “almost” records, but which ended up not using @AutoValue. A survey of
these might help us decide what changes we could make to increase adoption, or
simply confirm for us, “Yes, it’s a good thing we included restriction X,
because this class is a bad candidate for a record, but without restriction X
it might have become a record”. Alas, unsurprisingly, it is much easier to find
actual @AutoValue classes than to design a heuristic for “almost an
@AutoValue”, and so I have not done this.
This is desirable, but as you point out, hard to do — you can’t grep for
“@WishIWasAnAutoValue”. Often the best we can do is recall specific instances
of coding in the past when we tumbled off the cliff, and try to reconstruct
what was going on.
on this respect you can probably find useful class:
com.sun.tools.javac.comp.Analyzer, we have used to find things like what
initializations could be diamonds or lambdas, etc. Most recently it was
used to find out what explicit variable declarations could be
substituted by `var`. This analyzer is very powerful. I can help
providing an analyzer that you can test on your code base. Could you
please share some of the patters of those could-have-been-autovalue
classes?
* Records can expect to be about as common as enums
Thanks,
Vicente
