[Suggestion]Support additional Data driven metadata in Reflected classes to get around reflection system shortcomings to give classes a standard way to be deeper integrated in present and custom tools.

Let me introduce the problem by a simple example.

Say that I want to add links to documentation in lua editor classes reference list so that when I press f1 I can open the browser on the exact page where the method is documented.Lua Editor seems to use the reflection capabilities to make this list and reflection system isn’t really appropriate to add this kind of capability.

Actually I didn’t know the details about how to do this, but it seems to be all but seamless as this or other custom needs may not really match the way reflection system cope with class metadata.

I may guess that you need to implement new reflection attribute and add it to every class source file then implement in the lua editor a way to use this newer reflected data.

This data is then always added to the overall weight of the reflected data and without changes to the build system its weight needs to be paid from anyone, also systems and tools that doesn’t use or understand this data at all.

This can be ok for data needed by the editor as it is the main tool all classes need to interface with, but looking at a wider ecosystem of tools everyone with it’s own custom data needs and no direct support from the engine or gem developers it is needed an external source of additional metadata to expand the capabilities of tools to truly interact with engine classes.Also classes in gems where not initially planned to support the specific tool.

There is then the need to add any metadata to engine and gems classes in a more seamless way without any recompilation needs.

So I think that the engine needs a fully data driven way to add metadata to reflected classes that can be access in some standard way from whoever makes request for it.

It needs to be based on text files (for versioning) , have a really fast read only access to this data and support hot reloading without restarting any tool(even the editor could make good use of this capability).

Asset processor, or similar concept, could be involved in this workflow.

Tools may make requests to it to extract the requested data from multiple places and cache it in some binary version containing just the intended pieces it may also watch for changes in text files and do cache rebuilds that pushes data reloadings.

Sorry if some details doesn’t really match with the actual implementation.It was just to try expressing my point on this issue. It will surely need to be reworked to match the real implementation I don’t actually know.

Great suggestion again. I’ve passed it to the team!