Refactor non-core Curve methods into extension traits #16930
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
The way
Curve
presently achieves dyn-compatibility involves shovingSelf: Sized
bounds on a bunch of methods to forbid them from appearing in vtables. (This is called explicit non-dispatchability.) TheCurve
trait probably also just has way too many methods on its own.In the past, using extension traits instead to achieve similar functionality has been discussed. The upshot is that this would allow the "core" of the curve trait, on which all the automatic methods rely, to live in a very simple dyn-compatible trait, while other functionality is implemented by extensions. For instance,
dyn Curve<T>
cannot use theSized
methods, butBox<dyn Curve<T>>
isSized
, hence would automatically implement the extension trait, containing the methods which are currently non-dispatchable.Other motivations for this include modularity and code organization: the
Curve
trait itself has grown quite large with the addition of numerous adaptors, and refactoring it to demonstrate the separation of functionality that is already present makes a lot of sense. Furthermore, resampling behavior in particular is dependent on special traits that may be mimicked or analogized in user-space, and creating extension traits to achieve similar behavior in user-space is something we ought to encourage by example.Solution
Curve
now contains onlydomain
and thesample
methods.CurveExt
has been created, and it contains all adaptors, along with the other sampling convenience methods (samples
,sample_iter
, etc.). It is implemented for allC
whereC: Curve<T> + Sized
.CurveResampleExt
has been created, and it contains all resampling methods. It is implemented for allC
whereC: Curve<T> + ?Sized
.Testing
It compiles and
cargo doc
succeeds.Future work
Curve<T>
whereT: Animatable
into anAnimatableKeyframeCurve
).CurveExt
might be further broken down to separate the adaptor and sampling methods.Migration Guide
Curve
has been refactored so that much of its functionality is now in extension traits. Adaptors such asmap
,reparametrize
,reverse
, and so on now require importingCurveExt
, while the resampling methodsresample_*
require importingCurveResampleExt
. Both of these new traits are exported throughbevy::math::curve
and throughbevy::math::prelude
.