Determine the best ABI/naming convention used in mirrors for identifying and organizing the different parts of RTI.

[zackeryfix]

We need to set a standard ABI to use when generating mirrors that point to the various kinds of RTI recognized by the reflection engine. An ABI (or Application Binary Interface) is used to represent symbols within an executable file. This is useless as far as the framework is concerned during the current phase of development, but in later stages the ABI will prove very useful if we define it early on. Well, I wouldn't say that the ABI is useless, because we need it to generate unique mirrors for identifying RTI stored by the framework at compile-time, and referencing the RTI during runtime. I have devised the following rules that are defined strictly by a set of character symbols that are used as markers in the mirror primarily as a means of quickly parsing and identifying the RTI construct that they represent:

• | - AssemblyInfo
• : - NamespaceInfo

• - TypeInfo

• @ - FieldInfo
• $ - MethodInfo
• , - ParameterInfo
• () - parameter list start/stop
• % - whitespace separator
• ? - followed by a TYPE or METHOD, with each ? representing the ABI for a template parameter
• type - The ABI for a TYPE construct used in a parameter list or return type
  1. The very first token in a full name ABI will always be the name of the shared object file (.DLL in Windows, .SO in Unix). This library file will reside in the CACHE directory set by the current version of the Ngen runtime, and a LIBRARY may contain one, or more than one loadable ASSEMBLY.
  2. If the LIBRARY has no NAMESPACE, then an ASSEMBLY must be created using the name of the LIBRARY (or another appropriate name), and a NAMESPACE must be created using the name chosen for the ASSEMBLY. This allows RTI support for C/C++ libraries that exist prior to the Ngen framework, such as OpenGL (which does not have a NAMESPACE).
  3. ALL members of an ASSEMBLY must reside inside a NAMESPACE, and all members of a LIBRARY must reside in an ASSEMBLY.
  4. The top most NAMESPACE must reside inside an ASSEMBLY (as stated by 3), and a NAMESPACE may have up to a depth of 10 (pre-defined constant) nested NAMESPACE constructs.
  5. The top most TYPE must reside inside a NAMESPACE (as stated by 3), and a TYPE may have up to a depth of 10 (pre-defined constant) nested TYPE constructs.

This may be confusing, but stay with me. These five rules clearly outline the following examples of valid full name ABIs. (Note: these are examples for FULL name ABIs, but in the framework all RTI is store locally within the construct they directly belong to and FULL name ABIs are only used when attempting to access RTI where the directly related construct is unavailable.):

Ngen::Reflection::AssemblyInfo

LIBRARY|ASSEMBLY

Ngen::Reflection::NamespaceInfo

LIBRARY|ASSEMBLY:NAMESPACE:NAMESPACE namespace { namespace { } }

Ngen::Reflection::TypeInfo

LIBRARY|ASSEMBLY:NAMESPACE#TYPE namespace { class { }; }

Ngen::Reflection::TemplateTypeInfo

LIBRARY|ASSEMBLY:NAMESPACE#TYPE?? namespace { template<typename T, typename T2> class { }; }

Ngen::Reflection::FieldInfo (nested inside NAMESPACE)

LIBRARY|ASSEMBLY:NAMESPACE@type%FIELD namespace { _type_ Field; }

Ngen::Reflection::FieldInfo (nested inside nested TYPE)

LIBRARY|ASSEMBLY:NAMESPACE#TYPE#TYPE@type%FIELD namespace { class { class { _type_ Field; }; }; }

Ngen::Reflection::MethodInfo (nested inside templated TYPE)

LIBRARY|ASSEMBLY:NAMESPACE#TYPE?$type%METHOD(type%PARAM,?%PARAM) namespace { template<typename T> class { _return_ Method(_type_ param0, T param1) { } }; }

Ngen::Reflection::TemplateMethodInfo (nested inside NAMESPACE)

LIBRARY|ASSEMBLY:NAMESPACE$return%METHOD??(?%PARAM,?%PARAM) namespace { template<typename T, typename T2> _type_ Method(T param0, T2 param1) { } }; }

Notice in these examples that all trait information is excluded (such as const, public, private, static, etc). This is because most languages (including the C/C++ languages) do not allow for same name members existing inside the same code space. Our ABI will take advantage of this whenever possible, and trait information will be stored in the RTI itself (accessed by the ABI mirror representing it). Additionally, all whitespace characters are filled in by using % character. The reason for removing whitespace is for the executable storage requirements that will be used in the later phases of this project.

These are subject to change as the framework comes into light and unforeseen issues arise that conflict with this definition of the ABI.

[zackeryfix]

This ABI/naming convention should support ALL existing languages including scirpting languages that accept user input dynamically. For instance, we can easily write wrapper constructs to invoke interpreter executables through the OS and pass C++ data structures as arguments to the program for languages that do not have the concept of functions. For the languages that do not have a concept of namespaces, types, code spaces, or scopes, we will simply mimic them as if they did exist. Conceptual RTI in this framework will be a true common language infrastructure.

https://en.wikipedia.org/wiki/List_of_programming_languages

[zackeryfix]

This will be closed when the next version is cut.