Skip to content

Cleanup after behavior was clarified #7

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

Merged
merged 3 commits into from
May 10, 2021
Merged

Conversation

twof
Copy link
Owner

@twof twof commented May 8, 2021

There were some remnants describing how Swift force unwrapping works after Stephen clarified the behaviour to be similar to SDL non-null behaviour, so I've removed those.

@twof twof requested a review from lizjakubowski May 8, 2021 04:43
@twof
Copy link
Owner Author

twof commented May 8, 2021

@fotoetienne tagging you since this is relevant to some changes you made.

Copy link

@fotoetienne fotoetienne left a comment

Choose a reason for hiding this comment

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

I had one minor comment, but looks good!

@twof twof merged commit 27069c9 into QueryLevelNullability May 10, 2021
twof pushed a commit that referenced this pull request Oct 18, 2021
* Comments on the proposal

Hi, thanks for this extensive and in-depth work.

I will try to keep my comments concise (which might make them sound agressive, apologies if that's the case, it's definitely not the intent)

This PR touches one of the most challengeable founding philosophical choices of GraphQL: having 2 different type systems for input and output.

I understand that the sender -> receiver relation is an unbalanced one: the sender has obligations, the receiver has options.

However:
 - ALL GraphQL users use programming languages (Javascript, Java, C#, Python...) which make no difference between input and output types
 - I actually don't know any other protocol that does that (is there one?)
 - having 2 different type systems for input and output solves (does it?) an implementer problem, not a user problem

The lack of polymorphism on input is only a side-effect of the aformentioned original choice.
In an unreal world, rather than tweak GraphQL to fix that, it would be time for GraphQL2, unifying input and output types (amongst other improvements).

That's very unlikely to happen, but saying so helps forming an opinion on the various proposals:
 - adding yet another polymorphic construct only available on input 'smells' like increasing confusion 
 - it would increase the gap between input and output type systems, rather than reduce it

From there, I think proposal #5 @OneOf is the most useful one:
 - it acts as a constraint on existing type constructs rather than yet another type construct
 - it expresses the required behavior much better than proposal #7

* Comments on the proposal

Hi, thanks for this extensive and in-depth work.

I will try to keep my comments concise (which might make them sound agressive, apologies if that's the case, it's definitely not the intent)

This PR touches one of the most challengeable founding philosophical choices of GraphQL: having 2 different type systems for input and output.

I understand that the sender -> receiver relation is an unbalanced one: the sender has obligations, the receiver has options.

However:
 - ALL GraphQL users use programming languages (Javascript, Java, C#, Python...) which make no difference between input and output types
 - I actually don't know any other protocol that does that (is there one?)
 - having 2 different type systems for input and output solves (does it?) an implementer problem, not a user problem

The lack of polymorphism on input is only a side-effect of the aformentioned original choice.
In an unreal world, rather than tweak GraphQL to fix that, it would be time for GraphQL2, unifying input and output types (amongst other improvements).

That's very unlikely to happen, but saying so helps forming an opinion on the various proposals:
 - adding yet another polymorphic construct only available on input 'smells' like increasing confusion 
 - it would increase the gap between input and output type systems, rather than reduce it

From there, I think proposal #5 @OneOf is the most useful one:
 - it acts as a constraint on existing type constructs rather than yet another type construct
 - it expresses the required behavior much better than proposal #7

* Update InputUnion.md

* clean up merge dirt
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.

2 participants