Consider removing the "shape" moniker from abstraction APIs

[eiriktsarpalis]

The use of the term "shape" in the core abstractions is inherited from the F# TypeShape library. It was intended as a synonym to terms like "schema" or "spec", but in practice I suspect it's introducing more ambiguity than it should. We could either

1. Replace "shape" with a better moniker, i.e. ITypeSchema or ITypeSpec.
2. Remove the moniker altogether. This would better emphasize that the abstractions are just a strongly typed flavour of reflection as opposed to something different. The abstractions would then be named IType, IEnumerableType, ITypeVisitor, and IShapeable<T> would be renamed to something like IReflectable<T>.

cc @AArnott @eerhardt

[AArnott]

I think IType suggests a broader scope than you're targeting. You're focused on data (properties, fields, certain constructors) but not methods in general. "Shape" to me alludes to the data of the type rather than its behavior, which worked well IMO.

I'm hesitant to embrace "schema" because this library doesn't directly represent how objects are serialized, and schema in my mind dictates the structure of how something is serialized. But it's close, so I'd be ok with it, except that Nerdbank.MessagePack already has its own concept of schema, which documents exactly the serialized shape/structure/schema for a given type graph. Having "schema" used both in polytype and my library may confuse the user.

So just brainstorming here... IDataTypeSpec maybe? Or maybe ITypeData?

[eiriktsarpalis]

I think IType suggests a broader scope than you're targeting. You're focused on data (properties, fields, certain constructors) but not methods in general.

Agreed, although nothing prevents the abstractions from being extended to include method invocation like with constructors (apart from lacking a strong motivating use case). The underlying concept is strongly typed reflection fundamentally.

[eerhardt]

I agree to remove "shape" terminology, it does create confusion. I agree that IType is too broad. For some reason I do like "Spec" in the name.

ITypeSpec or IDataTypeSpec both seem decent.

Just a thought - but the library is called PolyType now right? Should we be using that term in the core abstractions? IPolyTypeSpec?

[eiriktsarpalis]

So just brainstorming here... IDataTypeSpec maybe? Or maybe ITypeData?

ITypeSpec or IDataTypeSpec both seem decent.

Does IDataType sound right? It should better emphasize that the library primarily caters to POCO/record types as opposed to classes with behavior.

Just a thought - but the library is called PolyType now right? Should we be using that term in the core abstractions? IPolyTypeSpec?

I think of "PolyType" more as the brand/repo/NuGet package name. Seems appropriate enough for namespaces but perhaps not as necessary for its types?

[trippwill]

Just my 2 pence as an interested bystander:

I liked Shape. Once I knew what it was, it made perfect sense as an abstraction that describes a type. Also, reflection is a "dirty" word in my circles, and one of the most exciting things about this library for me is the source generated metadata that can (mostly) avoid reflection. Schema is too overloaded a term, and I would find it confusing keeping one schema straight from another, especially when I need to do a little lower level work with serialization. Of the current suggestions, I think "Spec" is a good direction.

Here's a few curveballs that might inspire an idea: ITypePlan, IDataBlueprint.

[AArnott]

Consider #80 when thinking of the name