Some suggestions for changes (which I can implement)

[Ploppz]

Most of these suggestions, I will already implement locally as I work on my project (which uses plotlib to plot stuff). I will submit a PR after a while. Until then, I open this issue so that you may discuss or protest against some of my suggestions. I can then change or revert that point. So please state your opinion!
I will keep it updated as I think of new things.

• I think that taking Box<MyTrait> rather than &'a MyTrait in general makes a better programming interface, eliminating lifetimes. Examples: Page::add_plot and ContinuousView::add both take references to traits. In fact I was forced to change the latter function to add(mut self, repr: Box<ContinuousRepresentation>) because of lifetime issues in my project (more specifically, I created the data in a loop. The old solution would require me to store the data in a Vec and then loop again over that Vec to plot the data). It remains, however, to change to Box in other functions. Done in Start with legends, and less references #40

• [PR Make 3 common style structs, remove style traits #29] Naming: It's rather confusing to have struct line::Line, struct line::Style and also trait style::Line. I think we should find some way to rename them. Especially try to not make the Lines unique only through the module paths. We could for example name them struct Line, struct LineStyle and trait LineStyleTrait.

• [PR Make 3 common style structs, remove style traits #29] Remove the Style traits. I don't see the need for a trait for every kind of Style. The only one that has two implementors is style::Line. However these two implementors are identical.

• Naming: There are some opportunities for shorter names. Some words are quite commonly shortened, such as s/Representation/Repr.

• svg: Rounding errors in Y labels #18

[simonrw]

Hi thanks for these points.

I think that taking Box rather than &'a MyTrait in general makes a better programming interface, eliminating lifetimes. Examples: Page::add_plot and ContinuousView::add both take references to traits. In fact I was forced to change the latter function to add(mut self, repr: Box) because of lifetime issues in my project (more specifically, I created the data in a loop. The old solution would require me to store the data in a Vec and then loop again over that Vec to plot the data). It remains, however, to change to Box in other functions.

I think this is a good suggestion. I personally prefer boxed trait objects, as you say it will remove the lifetimes.

I don't like that there are only modules in the root. I find it better when the most useful / frequently used items are exported in the project root. This point is easy; just re-export in root.

I don't think currently we are at a stage where we can stablalise API yet. In the long run, as you say it would be good to move really common structs and traits in to the top level namespace, or perhaps include a prelude submodule for importing everything common. I feel however that a little inconvenience now is a minor setback while the API is changing.

Naming: It's rather confusing to have struct line::Line, struct line::Style and also trait style::Line. I think we should find some way to rename them. Especially try to not make the Lines unique only through the module paths. We could for example name them struct Line, struct LineStyle and trait LineStyleTrait.

I'm not personally keen on having Trait in a Trait's name, however we are open to suggestions on naming etc. We can keep this discussion open. Apart from this I like your suggestion.

Remove the Style traits. I don't see the need for a trait for every kind of Style. The only one that has two implementors is style::Line. However these two implementors are identical.

Perhaps e.g. the Line trait could be merged in with the Line struct. I'm sure common behaviour will appear in the future, perhaps with special types of lines but for now there is only one type of line.

Naming: There are some opportunities for shorter names. Some words are quite commonly shortened, such as s/Representation/Repr.

I am undecided. Text editors support autocomplete so it's not the typing that's the problem. Long names lead to long lines which are more difficult to read.

[simonrw]

I've been having a look into your first item, changing references to trait objects into owned trait objects (Box) to see how that changes the API. The changes can be seen here:

master...mindriot101:boxed-traits

In addition, for ergonomics I included From<T> impls for the boxed traits so the user does not have to create a box themselves (https://github.com/mindriot101/plotlib/blob/9673b037057107095432d759e691c95522b1a14c/src/histogram.rs#L210)

Some things I noticed:

• Using boxed traits moves the original structs to be owned by "parent" structs. This change in ownership may not be what the user wants. It might be worth considering implementing Clone for the more lightweight structs in case the user wants multiple plot elements which are identical.
• There is definitely a reduction in the number of references and lifetimes flying around. This is linked to the point before but could be considered an additional bonus.

[Ploppz]

I removed my previous comment, to write again. I implemented the suggestions related to styles in #29.

Your second comment:

• An alternative to the From approach, is to make add<T: ContinuousRepresentation>(...), and do the boxing itself.
• Yeah, I think implementing Clone is fine.