units icon indicating copy to clipboard operation
units copied to clipboard

remove named conversion factors

Open nholthaus opened this issue 5 years ago • 10 comments

Named conversion factors no longer appear in unit definitions, so I don't think we need them anymore if we change the macros around. It would save us a bunch of symbols, and remove an obsolete concept from the public interface.

I made a half-hearted attempt, but reverted when I ran in to trouble in the strong definitions.

nholthaus avatar Nov 05 '18 20:11 nholthaus

Please, remind me what did you mean by "named" conversion factors.

JohelEGP avatar Nov 05 '18 22:11 JohelEGP

what used to be meters etc but is now called meter_conversion_factor

nholthaus avatar Nov 05 '18 22:11 nholthaus

So you mean removing the strong conversion factors and leave only conversion_factor?

JohelEGP avatar Nov 05 '18 23:11 JohelEGP

I mean removing the entire UNIT_ADD_UNIT_TAGS macro

nholthaus avatar Nov 05 '18 23:11 nholthaus

so sometimes when you leave an issue open for two years, you don't really know what was going on and discover it wasn't a good idea. This is one of those. Not fully understanding the evolution of strong units didn't help.

This change regresses the error messages, but doesn't improve compile time. The readability gain in the definitions is more than offset by the readability loss to the user.

nholthaus avatar Oct 09 '20 00:10 nholthaus

The readability gain in the definitions is more than offset by the readability loss to the user.

The former can be retained. And I like it.

JohelEGP avatar Oct 09 '20 00:10 JohelEGP

How so, by refactoring the macros some more?

On Thu, Oct 8, 2020, 8:03 PM Johel Ernesto Guerrero Peña < [email protected]> wrote:

The readability gain in the definitions is more than offset by the readability loss to the user.

The former can be retained. And I like it.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/nholthaus/units/issues/209#issuecomment-705890133, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOYOHYL4VDRFPQZV3CPNR3SJZHLRANCNFSM4GB43IQA .

nholthaus avatar Oct 09 '20 00:10 nholthaus

By using the unit's conversion_factor member alias.

JohelEGP avatar Oct 09 '20 00:10 JohelEGP

Basically #256 without the bits that remove the strong conversion factors, thanks to this line:

 			abbreviation, ::units::decibel_scale, typename ::units::namespaceName::namePlural<UNIT_LIB_DEFAULT_TYPE>::conversion_factor) /** @} */ \

There are a few redundant UNIT_LIB_DEFAULT_TYPEs, though. The "diamond operator" <> does the job.

JohelEGP avatar Oct 09 '20 00:10 JohelEGP

so sometimes when you leave an issue open for two years, you don't really know what was going on and discover it wasn't a good idea. This is one of those. Not fully understanding the evolution of strong units didn't help.

I think I remember what happened. With strong units, meters or meters<> (actually meters<double>) could replace (strong) conversion factors. And error messages would've been even better. But strong units were reverted. I didn't put a reference to the comment where this idea spawned back then because I lost track of it.

JohelEGP avatar Oct 09 '20 18:10 JohelEGP