Very nice!

double +1 ;-)

-- Jon



On 06/04/2019 04:53 AM, Hannes Wallnöfer wrote:
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


Reply via email to