Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quantity aliasing #78

Closed
Aehmlo opened this issue Apr 20, 2018 · 1 comment
Closed

Quantity aliasing #78

Aehmlo opened this issue Apr 20, 2018 · 1 comment

Comments

@Aehmlo
Copy link
Contributor

Aehmlo commented Apr 20, 2018

There are applications where units that evaluate to the same thing have very different meanings (torque vs. work, pressure vs. stress, etc.). It seems less-than-ergonomic to me to require the user to use si::pressure::megapascal (or use si::pressure as stress or whatever) for a stress of 1 MPa, for instance. I would like to see some way to have units duplicated under another name using DRY principles, although I'm not sure what this would look like (possibly just some new syntax in the system! macro?).

@iliekturtles iliekturtles changed the title Quantity aliasing? Quantity aliasing Apr 22, 2018
@iliekturtles
Copy link
Owner

I've been thinking/experimenting with this for a long time under #3 because thermodynamic temperature and temperature interval both have the same dimensions. Will continue my efforts under this issue since the problem is spelled out explicitly.

Current thought is to add another PhantomData member to Dimension to distinguish between quantities with the same actual dimensions. I haven't fully explored the idea however.

iliekturtles added a commit that referenced this issue May 20, 2018
The new `Kind` associated type, defaulting to `()`, allows for multiple
quantities that have the same dimensions to be defined. Quantities of
different kind are not comparable. Resolves #78.
iliekturtles added a commit that referenced this issue Jul 7, 2018
The new `Kind` associated type, defaulting to `()`, allows for multiple
quantities that have the same dimensions to be defined. Quantities of
different kind are not comparable. Resolves #78.
iliekturtles added a commit that referenced this issue Jul 9, 2018
The new `Kind` associated type, defaulting to `()`, allows for multiple
quantities that have the same dimensions to be defined. Quantities of
different kind are not comparable. Resolves #78.
iliekturtles added a commit that referenced this issue Aug 4, 2018
The new `Kind` associated type, defaulting to `()`, allows for multiple
quantities that have the same dimensions to be defined. Quantities of
different kind are not comparable. Resolves #78.
iliekturtles added a commit that referenced this issue Aug 4, 2018
The new `Kind` associated type, defaulting to `()`, allows for multiple
quantities that have the same dimensions to be defined. Quantities of
different kind are not comparable. Resolves #78.
iliekturtles added a commit that referenced this issue Aug 5, 2018
The new `Kind` associated type, defaulting to `uom::Kind`, allows for
multiple quantities that have the same dimensions. Quantities of
different kinds are not comparable. The marker traits implemented by a
quantity's `Kind` control which operations are automatically
implemented. Resolves #78.
iliekturtles added a commit that referenced this issue Sep 6, 2018
The new `Kind` associated type, defaulting to `uom::Kind`, allows for
multiple quantities that have the same dimensions. Quantities of
different kinds are not comparable. The marker traits implemented by a
quantity's `Kind` control which operations are automatically
implemented. Resolves #78.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants