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

Fix an issue with generate_pretty and empty objects in the Ruby and Java implementations #449

Merged
merged 1 commit into from Oct 20, 2020

Conversation

chrisseaton
Copy link
Contributor

@chrisseaton chrisseaton commented Oct 7, 2020

Fixed #441.

@chrisseaton chrisseaton force-pushed the pretty-empty branch 2 times, most recently from 61efee1 to f5916bd Compare October 7, 2020 02:33
@chrisseaton
Copy link
Contributor Author

Also fixes #440 now.

@chrisseaton chrisseaton changed the title Fix an issue with generate_pretty and empty objects in the Ruby implementation Fix an issue with generate_pretty and empty objects in the Ruby and Java implementations Oct 7, 2020
}
depth = state.depth -= 1
result << state.object_nl
result << state.indent * depth if indent
unless count.zero?
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we use unless first to handle this instead of adding count?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't quite sure about what the 'object' could be and wether it was possibly an enumerator that can only run once?

Copy link
Contributor

Choose a reason for hiding this comment

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

first == true is always equivalent to count == 0, isn't it? (they're modified together in the current diff)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah I see what you mean! Yes I'll do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done - I thought you were suggesting I called .first on the contents.

@chrisseaton chrisseaton force-pushed the pretty-empty branch 2 times, most recently from 89001db to 31b9817 Compare October 7, 2020 12:31
Copy link
Contributor

@eregon eregon left a comment

Choose a reason for hiding this comment

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

Looks good to me.
@hsbt Could you review and merge?

@headius
Copy link
Contributor

headius commented Oct 7, 2020

It would be helpful to give a JRuby contributor write access to this repository, if this is where we will continue to manage the json extension. That person should probably be me.


final boolean[] firstPair = new boolean[]{true};
object.visitAll(new RubyHash.Visitor() {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is fine for the patch, but it's now constructing two objects instead of one. Making this an inner class with an accessible firstPair field would get it back down to one object.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, read it out of the object field, yeah.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It turned out to be quite a lot of refactoring to make the field accessible, as the local holding the visitor needs a new named class or interface in order to be able to read a field out of it, so I didn't do this change. I don't know if you want to @headius? Otherwise I'll leave it as is.

@hsbt hsbt merged commit 01e4823 into flori:master Oct 20, 2020
@headius
Copy link
Contributor

headius commented Dec 8, 2020

I believe this has not been released yet... so I am requesting a release! We were unable to resolve jruby/jruby#6338 in JRuby 9.2.14.0 because we do not ship prerelease code for default gems.

This was referenced Mar 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants