Increased transform flexibility

[scottmcm]

I think this bit of #12 is clearly worth doing, since it just makes things more flexible.

It seems obviously good to be able to .transform(…) slices too, not just Vec.

[rscarson]

First I want to say I really appreciate the work you've put into the project, but I will not be able to merge this as is, since it breaks two invariants of the trait:

• Transforms should be reusable, so removing the &t will not work here
• transformed specifically operates on a copy of the data - it is the clone variant of transform, which operates in place

However I think this does reveal some flaws in the transforms, namely:

• We do need more flexible implementations, such as slices . Perhaps the trait should be split into in-place and copied traits
• I also think this is fundamentally a failure of my documentation to adequately communicate these invariants

[scottmcm]

• transformed specifically operates on a copy of the data - it is the clone variant of transform, which operates in place

I'm not sure I follow this response -- that's what it still does, it just copies the data using .to_owned() instead of .clone(), so that you can "copy" the slice into a vec, rather than being restricted to Sized.

• Transforms should be reusable, so removing the &t will not work here

Definitely curious to see what "reusable" means to you here. After all, the impl Transform for &impl Transform this added means you can always re-use a Transform in Transformable::transform by using a reference to it.

[scottmcm]

annot: note specifically here that it's still making a copy of it https://doc.rust-lang.org/std/borrow/trait.ToOwned.html

[rscarson]

Ok fair point - I concede that the ToOwned version is more general.

However I still want to keep the &R here
implementing Transform for &Transform makes it compatible but imho encourages stateful or single use transforms, which I don't love

[scottmcm]

To me the thing that enforces that is that https://docs.rs/polyfit/latest/polyfit/transforms/trait.Transform.html#tymethod.apply takes &self, which I do not propose to change. You'd still have to use Cell or similar to make a stateful transform as a result.

I just got sad having to do blah.transform(&NormalizationTransform::MeanSubtraction); when the & didn't really seem to help anything at all, vs being able to just blah.transform(NormalizationTransform::MeanSubtraction);.

[rscarson]

Readme is a generated file (cargo rdme), please don't directly alter it - also this instance is already gone

[scottmcm]

I did this with cargo rdme because the PR build failed originally without it.