Constant bikeshedding about dimensioned HOT 7 CLOSED

Thinking about this more, we're definitely going to want to include a lot of constants, for things like

const ft: Meter<f64> = Meter::new(0.305);

but maybe that would be better as a generic function?

from dimensioned.

It looks like you've hit on a reason for defining constants: it actually
enables you to abstract away the base units, in a sense, since there is no
difference between m and cm. But maybe the constants should go in a
separate optional module?

On Mon, Oct 24, 2016, 12:11 AM Paho Lurie-Gregg [email protected]
wrote:

Thinking about this more, we're definitely going to want to include a lot
of constants, for things like

const ft: Meter = Meter::new(0.305);

but maybe that would be better as a generic function?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIZKUjmVes_8oAwL9dkKQLBh_jVm3IIks5q3Fo2gaJpZM4KeXK0
.

from dimensioned.

I think having the constants/conversions factors in the library is what will make it valuable. It also gives a single, reviewed, source for all constants, instead of every user having to enter any needed conversions on their own.

I've been doing some experiments (most current at https://github.com/iliekturtles/uom/tree/dev-8) and ended up with the base struct being Length and not Meter or Foot. Conversion factors are used internally and also exposed as enum variants: length::Units::meter, length::Units::foot, ...

from dimensioned.

Constants are in for sure, so I've renamed this as there are some open questions.

Say, for example, that we have the module si with the SI system defined in it.

Structure

Do we also have consts in that module? On the plus side, that makes them quite nice to use, as you can use dim::si; then things like let v = 3.9 * si::m / si::s; are both concise and clear. On the down side, if you wish to do a glob import from si, that could get ugly. We could also make an si::prelude module for glob imports of just the types, but that could be a pain to define without a build script.

Type

What primitive should consts be? I think f64 is a good default, but it'd be nice to have f32 ones also. This could be done either with a si::consts32 module, or with names like si::m32. I don't know what's best.

Functions

In addition to consts, do we also define functions? We already have things like Meter::new(3.0), but something like 3.0.m(); could be nice. It has the benefit over consts that it could be generic, and the same function could work for f32 and f64.

from dimensioned.

In my experiments (https://github.com/iliekturtles/uom/blob/dev-8/src/si/mod.rs#L32) I went with both f32 and f64 consts with the intention to add default features for both so that the undesired consts could be disabled.

from dimensioned.

That seems like a good idea. What I have now is, in each unit system, an f32consts module and an f64consts module, with a pub use f64consts::*. So users have access to both, but f64 is a bit more convenient.

from dimensioned.

I think this is settled.

from dimensioned.