-
Notifications
You must be signed in to change notification settings - Fork 32
Description
We should figure out if our transform traits are for implementing methods more easy, or for something like type restriction or something like type-erasing, and make a re-design.
1 | Trait composing
Assume we have ShiftTransform RotateTransform and ScaleTransform, we may want some item have something like AffineTransform.
We cannot auto-impl shift, rotate, scale from affine, because for them all we also have impl<T: XXX> for [T] auto-impl, and it can cause overlap.
We may restrict AffineTransform: ShiftTransform + RotateTransform + ScaleTransform, but the implementation is not quite forward.
2 | Method naming problem
Some problem we have now:
For DVec3 it has some method like:
fn rotate_axis(self, axis: DVec3, angle: f64) -> Self
fn rotate_x(self, angle: f64) -> SelfAlthough we want consistency between our rotate method and it, but we can't let them have the same name (since the trait methods have lower priority than impl methods). So for now, in #129, we have:
pub trait RotateTransform {
/// Rotate the item by a given angle about a given axis.
fn rotate_on_axis(&mut self, axis: DVec3, angle: f64) -> &mut Self;
/// Rotate the item by a given angle about the X axis.
fn rotate_on_x(&mut self, angle: f64) -> &mut Self {
self.rotate_on_axis(DVec3::X, angle)
}
/// Rotate the item by a given angle about the Y axis.
fn rotate_on_y(&mut self, angle: f64) -> &mut Self {
self.rotate_on_axis(DVec3::Y, angle)
}
/// Rotate the item by a given angle about the Z axis.
fn rotate_on_z(&mut self, angle: f64) -> &mut Self {
self.rotate_on_axis(DVec3::Z, angle)
}
}Which is not very ideal。