inline namespace constants

[nholthaus]

in the spirit of our other namespace inlining, I'm inlining the constants namespace as well

[coveralls]

Coverage remained the same at 100.0% when pulling 4cbe8b4 on inline-constants-namespace into dca7db2 on v3.x.

[JohelEGP]

I hadn't suggested it due to constants like h, which clash with their equivalently named conversion_factor, due to my desire now expressed in #196, and future constants possibly having the same problem. Not that I suggest using the conversion_factors with the abbreviated name.

[nholthaus]

yeah I think we should just change the names of the factors right?

…

On Fri, Oct 26, 2018 at 3:47 PM Johel Ernesto Guerrero Peña < ***@***.***> wrote: I hadn't suggested it due to constants like h, which clash with their equivalently named conversion_factor, due to my desire now expressed in #196 <#196>, and future constants possibly having the same problem. Not that I suggest using the conversion_factors with the abbreviated name. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#202 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ2HH0cH_4y_7unZvX9l9dGRJ8wkHUcKks5uo2bcgaJpZM4X80J7> .

[JohelEGP]

What do you mean? Right now, we have m, meter and meters, which are conversion_factors, and the unit meter_t. Following the units' renaming, there would be m and meter, and meters, respectively. There's also the issue of #159 (comment).

[nholthaus]

@JohelEGP once I clear the PR queue, I'm thinking of ding the unit rename, e,g. removing the _t. To do that, I'll first have to change the conversion factor names. I'm thinking unit_name_singular + _conversion. What do you think?

Once that's done, the abbreviations will be free again and we can do the h(1) defines, as well as define the SI unit of each dimension in core.h

[JohelEGP]

That sounds good. I'll tell you if I can come up with anything better.