Extending builders: PathBuilder

[Eva Krejcirova]

On 22.11.2012 14:18, Richard Bair wrote:
>>>> There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g.
>>>>
>>>> PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build();
>>>> or
>>>> PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build();
>>>>
>>>> There are several approaches for this :
>>>>
>>>> 1.) appending everything into one list so both of former examples return the same path.
>>> This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed?
>> What if somebody uses a single Group builder instance which is configured with common attributes and then used for building multiple Group-s each of them having different set of children. In that case I would expect children replacing and not adding to the existing list.
>
> Good argument.
Ok, so are we back at option 4 then?  That was following behavior:

Calling elements() erases all previous calls to elements(), moveTo(), 
...  New methods moveTo, lineTo etc. will add the element even if there 
already are some elements added by elements() call previously, they will 
not erase anything. This will not break backwards compatibility and will 
be consistent with other builder methods and has clearly defined behavior.
e.g.
PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new 
ClosePath()).build(); will only contain ClosePath
PathBuilder.create().elements(new 
MoveTo(10,10)).lineTo(100,100).closePath().build(); will contain MoveTo, 
LineTo, ClosePath

Eva