RFR: 8214126: Method signatures not formatted correctly in browser

Hannes Wallnöfer hannes.wallnoefer at oracle.com
Mon Jun 3 16:21:17 UTC 2019


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 <jonathan.gibbons at oracle.com>:
> 
> 
> 
> 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



More information about the javadoc-dev mailing list