Proposal: Add Interface inheritance for definitions

[SerafimArts]

Spec (http://facebook.github.io/graphql/#sec-Interfaces) does not proposes this feature. But this is will be good for ISP (Interface Segregation Principle) as example.

Example:

Base definitions

interface Creatable {
    createdAt: String!
}

interface Updatable {
    updatedAt: String
}

Variation of implementation

interface Person extends Creatable, Updatable {
    id: ID!
    name: String!
    # ...
}

class User implements Person {
    # Impl of interface fields: 'id', 'name', 'createdAt', 'updatedAt'
}

Interface fields overriding

Discussion needed. I think. e.g. how to consider the LSP (Liskov Substitution Principle)?

1. Allows NonNull for Nullable fields?
2. Allows ListType for "Single" type def?
3. Allow to increase/decrease the number of arguments for field input?

# Example
interface HasDates extends Creatable, Updatable {
    updatedAt: String! # Overriding nullable field
}

Errors

1. Error while cyclic inheritance

interface A extends B { ... }
interface B extends A { ... }

2. Error inheritance twice

interface Person extends Creatable, Updatable { ... }

type User implements Person, Creatable {
    # Error: Can not implement "Creatable" interface. Interface already defined in Person.
}

Like everything foreseen, there are ideas? =)

[SerafimArts]

Ooops... It seems like a duplication of #295

[tylercrompton]

It's similar but not related. Inheritance implies that the parent interface's fields are implicitly included in the child interface's schema. Additionally, you've touched on the topic of multiple inheritance and overriding properties of inherited fields. Neither of these are proposed in #295. I think that it's fair to say that this is different enough to not be a duplicate. However, the proposals conflict (in that they accomplish similar goals in different ways) and thus should be considered as mutually exclusive.

[SerafimArts]

@tylercrompton Convincingly, I'll reopen ann issue =)

However, I note that interfaces just exist to solve the problem of multiple inheritance and attach this link here: https://en.wikipedia.org/wiki/Interface_segregation_principle

At the moment the interfaces are a rudiment without the corresponding functionality.

[tylercrompton]

I think that for the sake of development and transition, we should consider deferring multiple inheritance and possibly "strictification" of types as well to a separate issue, pending the adoption of the simplified version of your proposal. In other words, I think that this proposal should focus solely on regular inheritance (for now) for the sake of getting at least something workable approved.

Additionally, your proposal introduces the diamond inheritance problem since types can implement multiple interfaces. We need to address this by identifying the desired mitigation algorithm.

[Recio]

So according to this issue, it seems that implicit inheritance is still not supported?

Is it strictly necessary to declare all the fields when implementing an interface?
That seems to lead to a lot of duplicated code...

There is no extension / polymorphic mechanism with implicit field inheritance in graph?

[SerafimArts]

@Recio You can use custom directives to implement this behavior. This is exactly what I did:

directive @extends(type: String!) on OBJECT

type Some { ... }
type Some2 @extends(type: "Some") { ... }

But I had to get inside the building pipeline to implement the logic of these directives.

[Recio]

@SerafimArts I'm a bit of a newb on the matter, but I suppose on build you inject the code from Some into Some2 ?

[SerafimArts]

@Recio in my case everything is different. I do not know how it works in the JS, because I implement my own SDL compiler =)

[leebyron]

See: #500 (comment)

TL;DR this proposal doesn't allow new use cases that were not already possible and degrades readability of schema in the name of writing less, which goes against GraphQL's guiding principles