RFR: JDK-8237845 Encapsulate doclet options
pavel.rappo at oracle.com
Mon Jan 27 13:38:20 UTC 2020
I remember we had an offline conversation on whether we should use shorter
method names for accessing stuff [ stuff() ], or more familiar ones
[ getStuff()/hasStuff()/isStuff()/etc. ].
I remember saying that I had no strong opinion about it. Not thank I'm
rethinking it, but I can now see how some of the accessor methods look weird.
Unsurprisingly, those are the ones whose name starts with a verb. For example,
Naming is hard, no doubt about it. While giving something a name, that name
should not be expected to be the sole guide on how to use that something.
A name should be a good mnemonic.
We could put a top-level comment in both BaseOptions and HtmlOptions. Something
to the effect that "unless otherwise stated, the methods below do not have any
behavior beyond simply accessing stuff".
Otherwise, looks good.
> On 25 Jan 2020, at 00:33, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> Please review a conceptually simple review to encapsulate the fields holding the values of doclet options, in the BaseOptions and HtmlOptions classes.
> The encapsulation was done with an IDE. The fields are all changed to private access; the access methods are package-private by default, and public when necessary, although in general, there is no problem if it is determined they should all have public access. This is the same policy as was done for ToolOptions, currently in review.
> Some fields need public "setters". These were added manually.
> In a few places, code was simplified manually, joining short lines, or replacing `configuration.getOptions()` with just `options`.
> This is intended to be the last in the current round of option-code cleanup, for now, although I think there is scope for future work to rationalize the names of the fields and corresponding accessor methods.
> -- Jon
> JBS: https://bugs.openjdk.java.net/browse/JDK-8237845
> Webrev: http://cr.openjdk.java.net/~jjg/8237845/webrev.00/
More information about the javadoc-dev