There should only be selectables

[rbalicki2]

• When processing the GraphQL schema, we need two steps: first, do the entities, then do the selectables
• That's because we don't know if in user: User, User is scalar or object, and we categorize selectables by whether they're scalar or object selectables
• Instead, we can just have a single "Selectable" struct, and one has to look up what it points to to determine whether it is a scalar or object selectable.
• This simplifies a lot and seems worth it.

[rbalicki2]

Related to #780.

I think the difference between scalars and objects is overrated. e.g. imagine a Date scalar (an ISO string). One can select that as date, which returns the string itself. Or one can select date { formatted }. Or, one can select data { formatted __self } to get both.

Likewise, a User object. One can select that as user, which would be an empty object, and which would translate to user { __typename id }, or user { __self }, which is user: { __self: {} } or user { __self foo }.

So, for any selectable and any entity, it is always valid to select foo foo {} and foo { bar } and foo { __self }

So, IMO, this implies that an entity is not a scalar or object entity! Instead, whether something is a scalar or object entity lives in network_protocol_associated_data, and affects query generation, but not iso literals

[rbalicki2]

The distinction between client and server selectables makes sense, though, because a client selectable is "expanded" at merged selection set creation time.

But IMO it might be best to have a single selection struct which has a field on it associated_data: DefinitionLocation<...>, where the client info consists of selection sets, etc. and the server definition into consists of a pointer to an entity. This field is used to distinguish between server and client selectables.