Plans for the reflection API?

[DragosPopse]

As per #5301 and reading on #5565 . I understand the plan is to favor COM interfaces and move away entirely from the C API.

The current reflection API in slang.h seems to be wrapper classes around the deprecated C API.

I am currently writing odin bindings for the Slang API and I wanted to ask what are the plans (if any) on the reflection API. Will there be COM objects for it? Will the Reflections C API be nuked from existence in the foreseeable future?

I might be wrong in the following statement, but it seems weird to me to move this particular api to deprecated.h when there isn't an ABI-stable alternative to it at the moment.

Thank you for this project and looking forward to see where things go

[laurooyen]

Hi, I'm currently working on making the generation of language bindings easier by directly contributing to this project. I have my own Rust bindings for Slang which contain a lot of manual generation and depend on the C reflection API.

As mentioned in #4758, I believe the plan isn't to deprecate the C API in the near future. As part of looking into options for binding generation in #5646, I was told they want to convert the reflection API to COM. Personally I would like the reflection API to be converted to COM as well because this would unify the API's. Obviously COM is ABI safe so no issues there.

With all these language bindings I'm not sure if the right path is to maintain them upstream here, with the exception of C bindings. Low level bindings like my own slang-sys crate (basically vtables) are easy to generate but idiomatic wrappers like my slang crate could be more difficult to maintain here. Maybe next to a C generator I could implement a generator for an XML or JSON description of the COM API à la Vulkan API spec. This could then be consumed by third-party language bindings.

@csyonghe would love to hear your thoughts.

[csyonghe]

I am OK with keeping language bindings in separate repos if that makes things cleaner to work with. The C api should definitely be maintained here.

Is there a standard for such a json / xml com descriptor file? Are there any existing solutions to produce COM bindings from a json?

[DragosPopse]

if the plan is to convert it to COM then that's fine, i was only curious what was the way forward. If that's the agreed goal then my question was answered and the issue is solved.

@csyonghe IDL maybe? I think that's only for COM objects, i'm not sure if it includes ways to describe the vanilla C procedures.

On the xml/json/idl/anything, currently the API is relatively small, I managed to write manual bindings to slang.h in a few hours, but some easier-to-the-eye format could help with some initial correctness in writing the bindings.

[laurooyen]

Is there a standard for such a json / xml com descriptor file?

Not that I know of. As far as I'm aware Vulkans XML schema is custom. The advantage of XML/JSON is that most languages provide plenty of options to read those formats.

I managed to write manual bindings to slang.h in a few hours

That's what I do for the COM interfaces in my bindings too. It's too error prone especially when keeping up with new releases.

By providing the API in a machine readable format, generating bindings from other languages should be much easier. It also lifts the burden of having to maintain all of those bindings here whilst giving implementors of said bindings the freedom to generate opinionated wrappers.

[csyonghe]

I support the idea to provide a json file for the com bindings to make downstream work of binding generation easier.

[laurooyen]

I'll continue work on the binding generator and try to provide C and JSON targets. Will file a separate issue to track that work.