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

Rename zeroth_xxx origins #653

Open
mpusz opened this issue Dec 5, 2024 · 8 comments
Open

Rename zeroth_xxx origins #653

mpusz opened this issue Dec 5, 2024 · 8 comments
Labels
refactor Modify existing code potentially causing breaking changes

Comments

@mpusz
Copy link
Owner

mpusz commented Dec 5, 2024

I am not a native English speaker, and zeroth felt strange to me from the beginning. When I present the library, most people in the room also complain about this name.

So far, we have:

  • zeroth_point_origin
  • zeroth_degree_Celsius
  • zeroth_degree_Fahrenheit

We need better ones.

@mpusz mpusz added the refactor Modify existing code potentially causing breaking changes label Dec 5, 2024
@JohelEGP
Copy link
Collaborator

JohelEGP commented Dec 5, 2024

At the start, I recommended something like "implicit" or "implied", which may not be a "zeroth".
Indeed, if a user writes quantity_point{1 * x} without reading the documentation,
they might be expenting some other kind of implied default origin.
Can you recavate the actual term I used?
This, of course, means, that other values of such points might not be compatible
(like quantities with equal dimension that are actually not of the same kind
in unit libraries that don't implement quantities and their kinds),
as their actual origin is not in the type system, unlike the current zeroth.

@JohelEGP
Copy link
Collaborator

JohelEGP commented Dec 5, 2024

A non-exclusive alternative would be to have another construction helper.
A refinement of point<x>, zeroth<x>, which implies the default zeroth value of an x.

@JohelEGP
Copy link
Collaborator

JohelEGP commented Dec 5, 2024

In fact, why not encourage the user of ADL with the construction helpers?
That makes them less noisy to use.
We can then ban quantity_point{1 * x},
and require either
1 * point(x) (for some point), or
1 * zeroth(x) (for some/the implicit zeroth),
and easily let users write their own,
which for their own program-defined point origins will work with ADL.

@mpusz
Copy link
Owner Author

mpusz commented Dec 5, 2024

The negative feedback was mostly about the word "zeroth" itself. Most people proposed to rename it to "zero" (e.g., zero_point_origin or zero_degree_Celsius).

@Spammed
Copy link

Spammed commented Dec 5, 2024

Is zero_point_origin a pleonasm?
Wouldn't origin<QuantitySpec> or zero_point<QuantitySpec> do the job?
I probably don't understand what it's all about again :-).

@JohelEGP
Copy link
Collaborator

JohelEGP commented Dec 5, 2024

The negative feedback was mostly about the word "zeroth" itself. Most people proposed to rename it to "zero" (e.g., zero_point_origin or zero_degree_Celsius).

Well, there's nothing ordinal about "zero".
"Zero point" seems like bad grammar,
and not like the "point" makes the "zero" an ordinal,
at least the way I see it.

"Point zero" seems better, but is that zeroth?
Is "point one" first? "Point two" second?

The reverse for the current "zeroth point"
would be "first point" and "second point".

If we take the suggestion of just replacing with "zero",
that'd also be "one point" and "two point".
Does that feel right?

@Spammed
Copy link

Spammed commented Dec 6, 2024

that'd also be "one point" and "two point"

In German, 'Nullpunkt' is the point at which the scale has the value 0.0.
leo.org translates 'Nullpunkt' into English as 'zero', 'zero point' or 'origin' etc.
Nobody would think of continuing with 'Einspunkt', 'Zweipunkt'.

@JohelEGP
Copy link
Collaborator

JohelEGP commented Dec 6, 2024

Nobody would think of continuing with 'Einspunkt', 'Zweipunkt'.

Yeah, zero alone might be the exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Modify existing code potentially causing breaking changes
Projects
None yet
Development

No branches or pull requests

3 participants