I was thinking about doing it the way you suggest, and I went ahead and did it.
New webrev with „fluent“ builder, no other changes: http://cr.openjdk.java.net/~hannesw/8214126/webrev.05/ Hannes > Am 04.06.2019 um 00:14 schrieb Jonathan Gibbons <[email protected]>: > > Much nicer. > > I'll offer one additional suggestion for your consideration; it is up to you > whether to take it or push as-is. > > Other low-level builders in javadoc support fluent usage by having a return > type of itself instead of void, and ending each method with "return this;" > > This, for example, the following: > > 154 MemberSignature sig = new MemberSignature(constructor); > 155 sig.addParameters(getParameters(constructor, true)); > 156 sig.addExceptions(getExceptions(constructor)); > 157 return sig.toContent(); > > could be simplified to: > 154 return new MemberSignature(constructor); > 155 .addParameters(getParameters(constructor, true)); > 156 .addExceptions(getExceptions(constructor)); > 157 .toContent(); > -- Jon > > > On 06/03/2019 09:21 AM, Hannes Wallnöfer wrote: >> I uploaded a new webrev with MemberSignature converted to a builder class: >> >> >> http://cr.openjdk.java.net/~hannesw/8214126/webrev.04/ >> >> >> Hannes >> >> >> >>> Am 28.05.2019 um 20:07 schrieb Jonathan Gibbons >>> <[email protected]> >>> : >>> >>> >>> >>> On 05/28/2019 10:59 AM, Jonathan Gibbons wrote: >>> >>>> >>>> On 05/28/2019 07:04 AM, Hannes Wallnöfer wrote: >>>> >>>>> From an implementation side, I created a new HtmlTree subclass called >>>>> MemberSignatureTree as an inner class of AbstractMemberWriter that >>>>> implements the display policies listed above. It is used by all member >>>>> signature writers, simplifying the #getSignature methods in various >>>>> MemberWriter classes quite a bit. >>>>> >>>> Just from reading the description in this sentence, and without looking at >>>> the code yet, the style for such objects is to make them be "builder" >>>> objects ... not inheriting HtmlTree but having a "toContent" method that >>>> generates the tree when all the relevant information has been provided via >>>> set/add/put methods. >>>> >>>> It makes sense to use a shared object to simplify the signature writes, >>>> but it doesn't sound right for it to be a subtype of HtmlTree, which is >>>> generally supposed to be a low level element that just has a tag, >>>> attributes and content. >>>> >>>> -- Jon >>>> >>> >>> For examples of existing builder-style classes, see Head, Table, >>> TableHeader. >>> >>> By deferring the construction of the HtmlTree, you can relax the order in >>> which the configuration methods are called, and can wait to make decisions >>> about the generated HTML until you have total knowledge of all the >>> component parts. >>> >>> -- Jon >>> >
