Benedikt Franke

Got it, I see how that could be necessary. Something we need to consider to avoid breakage is that `find()` or `findOrFail()` do not care about the name of the...

There is an issue with optional/nullable arguments when using classes to represent arguments/input types. I see no way to discern an argument that is not given vs. an explicit null....

I looked at the gist. Generally i like the idea, it takes a proven concept from Laravel and transfers it to Lighthouse - nice! We should really find another class...

Terminology is not the most important part of the functionality, but will be hard to change later if we get it wrong. Let's make sure the name fits in with...

> What about just calling it `Resolver` though? That would make `Resolver` have a weird double meaning, being a function and the thing that is passed to the function.

Some gems from https://relatedwords.org/relatedto/resolve: - Conflict - Negotiation - Question - Matters

I guess the reason for that might have to do with the AST manipulation that occurs within the `@paginate` directive: https://github.com/nuwave/lighthouse/blob/f1173128eb21f37f6a15805310ec993961098a92/src/Pagination/PaginateDirective.php#L63-L85

@enzonotario have you started work on `@morphOne` and `@morphMany`? I would like to get those in before the next release.

Have you considered https://lighthouse-php.com/master/security/validation.html#validator-classes? They support defining rules through arbitrary PHP code.

You can change the relevant docs here and create a PR: https://github.com/nuwave/lighthouse/tree/master/docs/master/subscriptions