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

Parameterize indent step in serlialize::json::PrettyEncoder #16601

Merged
merged 1 commit into from
Aug 21, 2014
Merged

Parameterize indent step in serlialize::json::PrettyEncoder #16601

merged 1 commit into from
Aug 21, 2014

Conversation

abonander
Copy link
Contributor

Previously, PrettyEncoder indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.

This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. PrettyEncoder::new() still uses the default of 2.

I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.

@alexcrichton
Copy link
Member

Could you add a test for this as well?


/// Creates a new encoder that indents `indent` number of spaces for each level
pub fn with_indent<'a>(writer: &'a mut Writer, indent: uint) -> PrettyEncoder<'a> {
PrettyEncoder { writer: writer, curr_indent: 0, indent: indent, }
}
Copy link
Member

Choose a reason for hiding this comment

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

This may be better done with a setter rather than a constructor in case more configuration is added later on.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A public setter? That could possibly allow the user to set a different indent in the middle of encoding. If the indent is larger than the previous value, then any

self.curr_indent -= self.indent;

has the potential to underflow. Would that just need to be a documentation warning then?

@abonander
Copy link
Contributor Author

@alexcrichton That's just it, I'm not sure what to test here. Maybe something that generates some JSON structures with different levels and checks the number of spaces at the beginning of each line?

@abonander
Copy link
Contributor Author

@alexcrichton I added a test for PrettyEncoder and cleaned up my fork's history. Do you think the test is too much? I'm waiting for the CI build to come back because the serialize test suite exits with a runtime error on my Windows machine:

The procedure entry point
_ZN3f649f64.Float8classify20hb3e5130924fcb90fGwaE could not be
located in the dynamic link library rustrt-4e7c5e5.dll

This is with a clean build from master + my changes. Have not yet tried a clean build before my changes.

@alexcrichton
Copy link
Member

That test looks great, thanks! I would still favor a configuration method with a warning about underflow (changing while serializing), however.

@abonander
Copy link
Contributor Author

@alexcrichton Okay, I have changed it to a setter. I figured out how to make it safe to set during encoding so we don't need a warning. And the test passes on my Linux machine.

bors added a commit that referenced this pull request Aug 21, 2014
Previously, `PrettyEncoder` indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.

This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. `PrettyEncoder::new()` still uses the default of 2.

I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.
@bors bors closed this Aug 21, 2014
@bors bors merged commit 1028120 into rust-lang:master Aug 21, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 25, 2024
fix: checkout repo before run typos

I see some typos at lastest master :(
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

Successfully merging this pull request may close these issues.

3 participants