User:KevinDietrich/Cycles Node Definition Language

Cycles Node Definition Language
This is a sketch of a language I designed to define Cycles Nodes.

Rationale
The goals were:
 * to cleanup usage of macros, and liberate ourselves from their shortcomings
 * to have a system to properly document each socket, with categories and tooltips/documentation for user interfaces
 * to more easily add data to SocketType (e.g. min/max information, doing so would require modifying a lot of macros currently)
 * to automate data validation e.g. the values of some socket may depend on the values of another one, although we could do this manually, automating this could lead to better code, fewer bugs due to typos
 * to support "socket groups", similar to the previous points, we could associate multiple sockets into groups to ensure that they are updated at the same with sensible values
 * to properly separate public and private APIs, where the public part is the one define from the metadata, and the private part is whatever Cycles needs internally to work on Nodes during Scene updates
 * to improve static initialization of reflection data, and allow for easy access to every NodeType's reflection data without having to include every header files, or creating a bogus Session (which is useful for generating UIs in external software using this metadata)

The idea was to define all of the metadata (sockets, documentation, etc.) of the various Nodes in files and generate C++ code from them at compile time. The generated C++ code would be a single base class for each Node containing just the socket types, from this base class Cycles would derive its own final class with any other members that it desires.

For example, the code for the Mesh Node would have been:

Only the MeshNode class would be exposed to the Cycles public API. Cycles would be allocating a Mesh, but returning a MeshNode whenever a new Mesh Node is requested, and similarly for any other Node type.

The main issue with this approach, is that base classes, like Geometry, are lost, or rather, it cat get tricky to treat Meshes, Hairs, and Volumes, as a simple pointer to some Geometry. Multiple inheritance could be considered though.