Extending builders: PathBuilder (original) (raw)

Eva Krejcirova eva.krejcirova at oracle.com
Wed Nov 28 06:57:48 PST 2012

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

More information about the openjfx-dev mailing list