Abstract Type Model

The Abstract Type model was written to provide a logical parity between how programmers think of types and their hierarchies, versus Reflection, which creates a lower-level generalization of types. The easier it is for a programmer to identify with the object model, relative to their code, the easier it should be to navigate.

To that goal, each common language construct has its own high-level class:
  1. Classes
    1. Binary Operator Coercions
    2. .ctors
    3. Events
    4. Fields
    5. Indexers
    6. Methods
    7. Properties
    8. Type Coercions
    9. Type Parameters
    10. Unary Operator Coercions
  2. Delegates
    1. Parameters
    2. ReturnType
    3. TypeParameters
  3. Enums
    1. Fields
  4. Interfaces
    1. Events
    2. Indexers
    3. Methods
    4. Properties
    5. Type Parameters
  5. Structs
    1. Binary Operator Coercions
    2. .ctors
    3. Events
    4. Fields
    5. Indexers
    6. Methods
    7. Properties
    8. Type Coercions
    9. Type Parameters
    10. Unary Operator Coercions

Each member kind represents unique aspects about that specific type. Struct members need to be aware that they're a part of a struct, same applies to classes.

Variations of this theme arise on structs, versus classes, in that struct methods cannot be extension methods, other interfaces of indexers, properties, et al. are given variations specific to classes and structs to give the members shorter names. IClassPropertyMember, for instance, is easier to type out and remember than IPropertyMember<IClassPropertyMember, IClassType> *Coercion members contain a single type-parameter and were deemed simple enough.

Last edited Oct 31, 2012 at 8:59 AM by AlexanderMorou, version 6

Comments

No comments yet.