Skip to content

Better transform traits system design #130

@AzurIce

Description

@AzurIce

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) -> Self

Although 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。

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions