Runtime Type Information (Reflection)
The RTTI system will benefit from runtime support in addition to the generated structures. Ideas for some runtime library functionality:
- On module initialisation, type information from that module is registered (see modules).
- Registration can construct additional cached links between structures such as backlinks from members to their parents and construction of other mappings from string to RTTI structures.
- Lookup of type info by name (using abovementioned mappings). E.g. the
lookup of
"Core::Buffer::t"would yield thetype_infostructure for that type (even if it is private). - Allocate an object from a
type_info. It will simply callmallocwith the appropriate size as found in the info. What to do with its members?- Uninitialised: Dangerous!
-
bzero'd (using memset): Has the problem that the representation of NULL may not actually be all bits zero, thus causes potential undefined behaviour on platforms where it's not. - Iterate over its members and initialise appropriately: More effort and
slower, but safe and portable. Perhaps some information could be cached about
the type, whether it is data-only or contains pointers. Data-only structs can be
memsetas an optional optimisation.
- Set members of an object. I'm not sure how to do this properly, as there
is no standard way to uniformly treat all kinds of data. Perhaps an
injectcould help handling this (similar toprintf). Runtime type checking should be performed by this function. - Read members of an object. This has similar issues as the above. It could
just return the same
datatypeas the member-set function and the callee must examine it (probably the best way). - Provide iterators (see iterators) for members, namespace children and contained structs, etc.
The runtime library would also contain predefined type info structures for built-in types.
This would be so much fun!