Skip to content

Adding ability to have lint rules for JSONFile, exposing extension in… - #49

Open
zsmoore wants to merge 1 commit into
devfrom
exposeFile
Open

zsmoore wants to merge 1 commit into
devfrom
exposeFile

Conversation

@zsmoore

@zsmoore zsmoore commented Jun 9, 2019

Copy link
Copy Markdown
Owner
  • Please check if the PR fulfills these requirements
  • [YES ] Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

#28

  • What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
    Exposes JSONFile to the linter, allows users to make lint rules for the file.
    Adds file extension to the JSONFile

  • What is the current behavior? (You can also link to an open issue here)
    You can't lint on JSONFile

  • What is the new behavior (if this is a feature change)?
    Lint rules for JSONFile can be created.
    File extension exposed

  • Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
    getObject is no longer usable but should not have been used outside of library.

  • Other information:

@zsmoore
zsmoore requested review from PawanHegde and ankuagarwal June 9, 2019 00:07
@zsmoore zsmoore self-assigned this Jun 9, 2019
}

private void initializeWrappedObjects(File file) throws IOException {
BufferedReader bufferedReader = new BufferedReader(new FileReader(file));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

We can use try-with syntax to ensure that this always gets closed no matter the exception
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

}

@Override
public void parseAndReplaceWithWrappers() { }

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

So does it still make sense to have this function in the interface if its implementation isn't necessary to be a WrappedObject?

throw new RuntimeException("Could not parse either a JSONArray or JSONObject from file");
}
public WrappedObject getChild() {
return wrappedJsonObject != null ? wrappedJsonObject : wrappedJsonArray;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why even have separate variables for wrappedJSONObject and wrappedJsonArray if at the end we only return a WrappedObject? We can have a single variable called wrappedChild and return that in getChild


@Override
public String report(JSONFile jsonFile) {
return "Expect a JSONArray as child";

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This message is misleading. Please change.

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