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

Tracks is a bad name #276

Open
KronosTheLate opened this issue Mar 16, 2022 · 5 comments
Open

Tracks is a bad name #276

KronosTheLate opened this issue Mar 16, 2022 · 5 comments

Comments

@KronosTheLate
Copy link
Contributor

After writing up #275, I am left with a strong feeling that the internal struct Tracks has a bad name. Why on earth would a type have a name with the plural form? If I construct a Tracks, in my mind, I have a single track, trace, or tracker. So I would much prefer Track, Trace, or Tracker to be the name of the type.

The way things currently are, things are not humanly readable in a meaningful way, but have to be memorized.

Any potential change would have to be made also for the tracks kwargument.

@jverzani
Copy link
Member

It comes from animal tracks (with the plural). I'm not wed to the name, or the plural, but I'd hate to change it now only because of it being modestly breaking.

@KronosTheLate
Copy link
Contributor Author

I know... Would it be possible to define one of the suggest names as const Suggested_name = Tracks for forwards compatibility, and make this change for some breaking upcoming release?

@jverzani
Copy link
Member

Sure, but let's come up with a good name. It really about recording a log and tracks just seemed okay in the moment. Maybe there is some more widely used naming scheme.

@KronosTheLate
Copy link
Contributor Author

KronosTheLate commented Mar 16, 2022

Could building on existing infrastructure be nice? I am thinking of ValueHistories specifically.

@jverzani
Copy link
Member

It isn't out of the question, but I'd like not to have to pull in new dependencies if possible. It might be better to mirror the API. I have a PR that incorporates some stuff we were just discussing. Adding better method names (e.g. not log_step and log_steps might be good.)

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