Extending Builders with custom code

[Daniel Fuchs]

Hi Michael,

As you noted making Builders immutable would break
backward compatibility.

Another interesting alternative could be to generate an
applyTo() method that takes another builder as parameter.

I am wondering whether the following would be doable:

For instance - today TextBuilder has a method:
   public void applyTo(Text x)

If it add an additional
   public (or even protected)  void applyTo(TextBuilder otherBuilder)

then we could possibly also generate a:

   public static TextBuilder create(TextBuilder initialConfiguration) {
	final TextBuilder newBuilder = create();
         initialConfiguration.applyTo(newBuilder);
         return newBuilder;
   }


Your example would then become:

final Text text1 = TextBuilder.create(builder).text("Hello 
World!").y(50).build();
final Text text2 = TextBuilder.create(builder).text("Goodbye 
World!").y(100).fill(Color.GREEN).build();
final Text text3 = TextBuilder.create(builder).text("JavaFX is 
fun!").y(150).build();

I believe it would address your requirement without introducing any
backward compatibility issue.

Just thinking out loud...

-- daniel


On 6/28/12 9:43 AM, openjfx-dev-request at openjdk.java.net wrote:
> From: Michael Heinrichs<michael.heinrichs at oracle.com>
> Subject: Re: Extending Builders with custom code
>
> Hi Evo,
>
> there was an interesting comment after one of my blog posts about reusing builders. Basically the commentator pointed out that making builders immutable would make them much better suited for reuse. The obvious solution, changing our builders, would break backward compatibility. But maybe you (or somebody on this alias) has a good idea how this can be achieved without breaking backward compatibility. Below is the full comment.
>
> Cheers,
> Michael
>
>
>
> Thanks for the post. I can clearly see the benefits of using builders and we have been using them in some areas in our code. Your post made me realize that reusing builders can be really powerful. Our application has a number of TableViews and each view has a number of columns. The builders are a perfect fit for the scenario where you want to create a number of columns that have many properties in common. You can use a TableColumnBuilder to create partial specification for the column and then stamp out the columns by setting the unique properties for each column and build() them (Similar to your text1, text2, text3 example above). The only problem is builders are not immutable. Every time you set a property on the builder it affects all future build events. In you example above, if you only want text2 to be green it would be nice if you were able to call it as follows:
>
> final Text text1 = builder.text(?Hello World!?).y(50).build();
> final Text text2 = builder.text(?Goodbye World!?).y(100).fill(Color.GREEN).build();
> final Text text3 = builder.text(?JavaFX is fun!?).y(150).build();
>
> But this results in both text2 and text3 turning green.
>
> I think making builders immutable will significantly improve the ability to reuse them. Consider the following example:
>
> TableColumnBuilder standardColumnBuilder = TableColumnBuilder.create()
> .prefWidth(50.0)
> .sortable(false)
> .editable(false);
> TableColumnBuilder narrowColumnBuilder = standardColumnBuilder
> .prefWidth(40.0)
> .resizable(false);
> TableColumnBuilder narrowColumnBuilder = narrowColumnBuilder
> .prefWidth(80.0);
>
> If builders were immutable I would now have three templates that I could reuse to build all the table columns but because they are not immutable I now have a ?standardColumnBuilder? that is not resizable and has a width of 80.
>
> Cheers,
> Ab
>
>
>
> On 27.06.2012, at 17:50, Eva Krejcirova wrote:
>
>> >Hi All,
>> >
>> >I am currently working on a system for extending our automatically generated Builder classes with custom code and I would like to ask for your help. Are you missing some convenience methods in existing builders? I would be happy to hear it! (preferably in a form of Jira issue ;-))
>> >
>> >Currently we have these Jira issues:
>> >* RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() methods to PathBuilder)
>> >* RT-16569 mentions the need for convenience methods in builders of layout classes (but doesn't specify it more)
>> >
>> >Thanks,
>> >Eva