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.

Sign up for GitHub

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

Jump to bottom

Create some type aliases for string Contexts #6235

Closed
wants to merge 1 commit into from
Closed

Create some type aliases for string Contexts #6235

wants to merge 1 commit into from

Conversation

Ericson2314
Copy link
Member

No description provided.

@Ericson2314 Ericson2314 mentioned this pull request Mar 12, 2022
Merged
thufschmitt
thufschmitt reviewed Mar 18, 2022
View reviewed changes
Copy link
Member

@thufschmitt thufschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small nit, but do what you want with it ;)

src/libexpr/value.hh
@@ -64,6 +64,8 @@ class JSONPlaceholder;

typedef int64_t NixInt;
typedef double NixFloat;
typedef std::pair<Path, std::string> NixStringContextElem;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe remove this and use NixStringContext::value_type instead? Doesn’t change much, but I find it more explicit

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe it should be this way to be consistent with SearchPathElem. which I had completely forgotten about in the time since I first wrote this code.

@edolstra
Copy link
Member

Not sure this is really an improvement. If I see std::pair<std::string, std::string> I know what it means, but if I see NixStringContextElem I have to look up what that type means. I.e. more cognitive overhead.

@Ericson2314
Copy link
Member Author

@edolstra The problem with std::pair<std::string, std::string> is that there are many other uses which don't have to do with the string context. Without having the alias (or better yet, writing a struct) one doesn't know which ones are for which purpose.

Concretely this also made #6237 easy (baring the GCC bug) because I could just change the definition in one spot.

@Ericson2314
Copy link
Member Author

Ericson2314 commented Mar 18, 2022 •
edited
Loading

Also c.f. SearchPathElem in this file, added by you in 363f37d ! :)

@fricklerhandwerk
Copy link
Contributor

@edolstra Naming types by what they mean is always better for readability. There are so many arguments for creating (the right!) abstractions, and the idea is so commonplace, that any serious source I can think about citing would already sound corny and stereotyped.

@Ericson2314
Copy link
Member Author

#6237 This contains and motivates this, so I will close this in lieu of that.

@Ericson2314 Ericson2314 deleted the string-context-typedef branch March 21, 2022 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@thufschmitt thufschmitt thufschmitt left review comments

@fricklerhandwerk fricklerhandwerk fricklerhandwerk approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@Ericson2314 @edolstra @fricklerhandwerk @thufschmitt