Extending builders: PathBuilder

[Eva Krejcirova]

Hi Matthieu,

Thanks for your feedback! Please see my comments inline.

On 7/13/2012 10:56 AM, Matthieu BROUILLARD wrote:
> Hello all,
>
> For me the strength of builder is that the user of the builder might not
> ask himself what the methods are doing, they have to be self explaining and
> there should be no ambiguity when using them.
> > From this then I would say that all the "final" methods in a builder should
> return not the builder itself but the built object.
> For example, if closePath() marks the end of the Path being built then just
> return the built Path and not the builder.
I think that it might be a little confusing - all builders have the same 
behavior: their methods just store the state and the built object is 
created when build() method is called and we would break this.
Also, you can continue building path even after closePath - 
moveTo(10,10).lineTo(20,20).lineTo(10,20).closePath().moveTo(30,30).lineTo(40,40).lineTo(30,40).closePath() 
is a valid path.

> For elements(), I have no strong arguments that either it should :
>
>     - contribute by adding path elements in the current path (like Michael
>     Paus suggests in the last comment of the issue)
I agree that this would be user-friendly, but unfortunately this would 
change current behavior of elements() and might break already existing 
apps. We should not break backwards compatibility if possible.

>     - be a full replacement of everything done before and then probably be a
>     final builder method
This is how I think it should behave (except for it being final builder 
method - even if we wanted it, we can't change the return type of 
elements(), it would break backwards compatibility).
>     - be splitted in addElements(...)&  replaceElements(...) which are more
>     self explaining
We could add such methods, but existing elements() method must remain 
there (backwards compatibility again :-)
> Personnaly, I would prefer the first one as it seems more natural to me.
>
> Another way also to clean the builders API in general can be to use some
> more interfaces. PathBuilder as filled in the Jira allows 2 categories of
> methods, the ones adding path elements and the ones modifying the graphical
> properties of the path being built.
> Saying that we could have it turned into:
>
> PathBuilder implements PathPropertyBuilder {
>      ...
>      PathBuilder lineTo(int x, int y);
>      PathBuilder addElements(PathElement ... elements);
>      PathPropertyBuilder  replaceElements(PathElement ... elements);
>      PathPropertyBuilder  closePath();
>      ...
> }
>
> PathPropertyBuilder {
>     ....
>      strokeWidth(int width);
>      strokeColor(Color c);
>      ....
>      Path build();
> }
Interesting idea! (Would be really hard to implement, though. The 
builders are generated automatically by our custom annotation processor, 
they are not written by hand)
>
> Perhaps my suggestions does not help you directly to take a decision, but
> as you asked for opinions, I give mine :-)
>
> Matthieu Brouillard
Thanks, there were some really interesting ideas!

Eva