Ability to inline objects for easier readability of the spec

[erikmaas-malmberg]

Is your feature request related to a problem? Please describe.
As and engineer I would love to inline types and Enums when they are not used in different places.
This improves the ease of use when reading the specification.
So instead of needing to switch the context of the type that one is reading by scrolling to the definition of a subtype, the reader can instead stay in the whole object instead.

Describe the solution you'd like
Instead of:

type Address {
  street: Name,
  houseNumber: Integer,
  postalCode: DutchPostalCode
}

type Person {
  firstname: Name,
  lastName: Name,
  age: Integer,
  address: Address
}

It would be great if we can do:

type Person {
  firstname: Name,
  lastName: Name,
  age: Integer,
  address:  {
    street: Name,
    houseNumber: Integer,
    postalCode: DutchPostalCode
  }
}

For naming the interanal objects the naming scheme of: can be used.
For the example this means: PersonAddress

Requirements
The ability to inline objects that are not reused in other places

Additional information
For further reading sources that triggered your feature wish

[jerrevanveluw]

I think I understand your need here. However this might raise more problems than it solves. If this indeed means PersonAddress this type could be defined elsewhere and clash. What would this mean for the Wirespec emitter? Are we emitting anonymous classes or the PersonAdress type? Of course there are other options like actually flattening the structure like this:

type Person {
  firstName: Name,
  lastName: Name,
  age: Integer,
  street: Name,
  houseNumber: Integer,
  postalCode: DutchPostalCode
}

For me the problem is mostly conceptually what "nestedness" means. What do you want to express with this nesting. To me it is re-use. And that implies naming it.

[erikmaas-malmberg]

For me it is not always reuse (though often it is). It is also grouping of a concept.
In the example that would be the concept of the address.

Naming can be by convention and thus can be checked while editing the spec.
It could indeed also be an inner class.
Or if we go very fancy, it can be controlled via an annotation.

Using these annotations would also make it possible to inline them while still sharing them as well.
Again, for readability of the spec. Even though writing it would be a bit more work (though with ide plugins this editing can be automated).