Skip to content

Clear-up disambiguity when using TypeExtension's and query shorthand #539

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

Closed
budde377 opened this issue Nov 27, 2018 · 2 comments
Closed

Comments

@budde377
Copy link

When implementing a parser from the spec. I had a hard time deciding on the right case when certain TypeExtensions are used with the query operation shorthand. Namely the EnumTypeExtension, InputObjectTypeExtension, InterfaceTypeExtension, and ObjectTypeExtension.

The issue arises with programs like the following:

extend interface Foo @somedir
{
  bar: String
}

this can according to the specification be interpreted as either

  1. the document containing a single InterfaceTypeExtension with the bar: String field definition (and a directive),
  2. or the document containing a InterfaceTypeExtension and a shorthand query with the field String aliased as bar.

Notice that the program

extend interface Foo
{
  bar: String
}

is unequivocally a document containing a single InterfaceTypeExtension.

I would like to get this ambiguity cleared up and would be happy to submit a PR with the right solution.

@IvanGoncharov
Copy link
Member

@budde377 sorry for delay.

GraphQL grammar is greedy that means if it will always optional tokens even if they are trailing.

As an example take number 12. Here is GraphQL grammar definition for integer numbers:
image

First character (1 in our example) matched by NonZeroDidgit but the second character (2 in our example) could be either match by optinal Digit or to be intepret as next number (since spaces are insignificant in GraphQL).
Obviously GraphQL always interpritate 12 as a single number because matching of optinal token is greedy.

Same rule works in your example and it should be always interpretated as a document contaning single interface extension.

I would like to get this ambiguity cleared up and would be happy to submit a PR with the right solution.

AFAIK GraphQL spec never mention that grammar is gready so it would be great if you add something about it into Apendix A
Note: GraphQL spec already has definition for optinal token it just never state that it will always prefer longest rule:
image

budde377 added a commit to budde377/graphql-1 that referenced this issue Feb 13, 2019
Explicitly state that the GraphQL grammar is greedy to clear up possible disambiguity.

Closes graphql#539
budde377 added a commit to budde377/graphql-1 that referenced this issue Feb 14, 2019
Explicitly state that the GraphQL grammar is greedy to clear up possible disambiguity.

Closes graphql#539
budde377 added a commit to budde377/graphql-1 that referenced this issue Feb 14, 2019
Explicitly state that the GraphQL grammar is greedy to clear up possible disambiguity.

Closes graphql#539
@IvanGoncharov
Copy link
Member

Closing this since progress is tracked as #564

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 a pull request may close this issue.

2 participants