Closed Palladinium closed 3 years ago
Thank you! Can you please give an example where this method would be preferred?
In my use case, I'm procedurally generating SVG paths, and I have a bunch of structs that construct path segments through Into<Command>
.
Without this PR, my options are:
match
over the returned command just to call the corresponding syntactic sugar method on Data
, which looks like an anti-pattern since the method just constructs another identical Command
Data
and mutate it, which makes it harder to chain nicelyData
and Vec<Command>
to intermix the syntactic sugar methods and pushing generic Command
s to the Vec
With this PR, I can write code like:
Data::default()
.move_to((10.0, 0.0))
.add(Thing.into())
.move_to((30.0, 0.0))
.add(Thing.into())
.close()
Which matches the way Document::add()
looks.
Good points! Thank you.
Data
is essentially a thin wrapper around aVec<Command>
with nice syntactic sugar, but there doesn't seem to be a way to passCommand
s directly into the buffer, and sometimes the syntactic sugar isn't the easiest way to go about things. This PR adds just that.