compiler: should definitions know their own name?

[SimonSapin]

As of 1.0.0-beta.4, the Schema struct contains types: IndexMap<Name, ExtendedType>. Each variant of the ExtendedType enum is a struct like this:

pub struct ObjectType {
    pub description: Option<NodeStr>,
    pub implements_interfaces: IndexSet<ComponentStr>,
    pub directives: Directives,
    pub fields: IndexMap<Name, Component<FieldDefinition>>,
}

Notably, these type definition structs do not contain a name: Name field. The reasoning is that the name is already in the map key, so having it in the struct as well would be redundant. And with a mutable data structure, eliminating redundancy eliminates the possibility of inconsistencies.

However:

1. This is a bit weird and unexpected
2. This pattern is not applied consistently. For example FieldDefintion is reused from the AST and does contain a name field, despite being in a name-indexed map when in a high-level Schema representation.

I think we should pick one pattern and apply it everywhere. Either nothing in IndexMap<Name, …> should duplicate its name (and have more dedicated structs in the schema module for FieldDefinition and others, instead of reusing AST ones), or everything should. Either way, this is breaking change that needs to happen before 1.0 leaves beta (or not happen).

[SimonSapin]

We’d like ExtendedType to implement Display by serializing to GraphQL syntax, like many other Rust types representing GraphQL elements do. This requires ExtendedType known its own name.

So proposed plan:

• Add pub name: Name to all relevant structs (or Option<Name> for executable::Operation)
• Add fn name(&self) -> &Name to the ExtendedType enum
• Document that it’s the user’s responsibility when mutating documents to keep names consistent between struct fields and map keys
• Provide code example for renaming an entry of such a map. (Remove from map at old name, set name field, insert into map at new name)