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

JSON: use enums instead of symbols #7966

Merged
merged 2 commits into from Jul 25, 2019

Conversation

@asterite
Copy link
Member

commented Jul 16, 2019

This changes JSON::Lexer and JSON::PullParser to expose enums instead of symbols for token kinds and pull parser state kinds. Symbols work but they are not type-safe. Plus enums gives enumerate (duh) all possible states.

The PullParser has already proven to be very useful but moving forward I wouldn't like to keep the Symbols interface so it's better now or never.

This is a breaking change:

  • JSON::Lexer::Token#type : Symbol is replaced by JSON::Lexer::Token#kind : JSON::Lexer::Token::Kind
  • JSON::PullParser#kind : Symbol is replaced by JSON::PullParser#kind : JSON::PullParser::Kind

To make it easy to upgrade I kept JSON::Lexer::Token#type : Symbol as deprecated and also made JSON::PullParser::Kind be comparable to symbols, with a deprecation notice. That way we don't actually break anything but if you run the compiler with --warnings=all then you can fix things at your time.

Once merged, in a subsequent PR I'll try to document all of these types, including the ones in the YAML module.

I also added JSON::Builder#next_is_object_key? because I think it's useful and I at least needed it for optimizing one thing in https://github.com/Blacksmoke16/oq (though I didn't send a PR there yet).

Show resolved Hide resolved src/json/builder.cr
Show resolved Hide resolved src/json/token.cr Outdated
Show resolved Hide resolved src/json/token.cr Outdated
@j8r

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

Even the Token class could be avoided, see https://github.com/j8r/con/blob/master/src/lexer.cr .
I was planning to do it, but never get enough time to.

@RX14

RX14 approved these changes Jul 20, 2019

@RX14

This comment has been minimized.

Copy link
Member

commented Jul 20, 2019

I'm not so sure about the symbol compatibility using ==, it seems very limited in the code which it will not cause a breaking change in. But I might be wrong.

@asterite

This comment has been minimized.

Copy link
Member Author

commented Jul 20, 2019

You mean it might cause a breaking change after all?

@RX14

This comment has been minimized.

Copy link
Member

commented Jul 20, 2019

Maybe? The only way to tell would be to find a corpus of projects which use these classes

@asterite

This comment has been minimized.

Copy link
Member Author

commented Jul 20, 2019

Even if it's not completely backwards compatibile I'd move forward with this. Upgrading it should be relatively straight forward.

@asterite asterite requested a review from bcardiff Jul 20, 2019

@asterite asterite force-pushed the asterite:json-refactor branch from b8520dc to cf3fd26 Jul 24, 2019

@asterite asterite force-pushed the asterite:json-refactor branch from cf3fd26 to a599924 Jul 24, 2019

@asterite asterite force-pushed the asterite:json-refactor branch from a599924 to 1c26bce Jul 24, 2019

@asterite asterite added this to the 0.30.0 milestone Jul 25, 2019

@asterite asterite merged commit 4c2d3b4 into crystal-lang:master Jul 25, 2019

5 checks passed

ci/circleci: check_format Your tests passed on CircleCI!
Details
ci/circleci: test_darwin Your tests passed on CircleCI!
Details
ci/circleci: test_linux Your tests passed on CircleCI!
Details
ci/circleci: test_linux32 Your tests passed on CircleCI!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@asterite asterite deleted the asterite:json-refactor branch Jul 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.