naming convention and cImport issue in the coming version of zig

[sugarme]

Hi,

I just tried some simple code on this qt6 zig binding and found the naming seem to be still in Go style. For example: function names in this lib start with an uppercase while Zig naming convention prefer lowercase. I wonder you meant doing that way?

On other issue, I looked at the Zig issues and breaking changes and see there an issue related to C binding that would affect to this libary: ziglang/zig#20630 . Do you think it will take long to update the cImport to be integrated into the build part?

[rcalixte]

Hi again!

I just tried some simple code on this qt6 zig binding and found the naming seem to be still in Go style. For example: function names in this lib start with an uppercase while Zig naming convention prefer lowercase. I wonder you meant doing that way?

This was actually something I debated back and forth while designing the API. I included in the README that the methods use PascalCase and that was intentional. If you look at the bindings for C, you'll notice they are lowercase with underscores so it wasn't an oversight. I know the recommendation for Zig but for the library, I thought it would be more readable to have the Qt methods be PascalCase, especially since the namespace structs and enums are all lowercase by default. There are other Zig libraries that have used this convention as well. If I choose to revisit this and change it, it would only be on a major change like Qt 7 but as of today, that is not likely.

On other issue, I looked at the Zig issues and breaking changes and see there an issue related to C binding that would affect to this libary: ziglang/zig#20630 . Do you think it will take long to update the cImport to be integrated into the build part?

If you grep the entire library, there are 0 instances of @cImport so this library is unaffected by that specific issue. I am subscribed to other issues that might impact the libraries or where I have a general interest so I am keeping an eye out. You'll notice that the libraries and the examples were also recently updated to Zig 0.15. These are the first public Zig version bumps but the libraries were built on Zig 0.13 and migrated to Zig 0.14 prior to being publicly released. I haven't outlined any specific details regarding the long-term plans here yet but the general idea is that only stable releases will be followed/supported by the libraries.

You should be safe to focus on consuming the libraries. As of now, the Zig releases have not been severely disruptive nor do I really anticipate them to be for these libraries but we'll see how that works out.

[rcalixte]

Zig naming convention prefer lowercase.

Maybe it's worth mentioning that if anyone has a strong preference for this, the full language features of Zig are available to you so you can do something like:

const show = qt6.qwidget.Show;

That is perfectly valid. In fact, for the inherited methods, an earlier version of the Zig library used this syntax in place of the full methods that exist now, so something like QPushButton had:

pub const Show = qwidget.Show;

There were also declarations in each header for the parent classes to support this. Ultimately, I settled on the full methods themselves since I felt they were more readable in place. I placed high value on being able to look through the file of a single class and see the implementation details without having to recursively open other files. It was initially a reluctant tradeoff over file size but long-term, it's proving to be the right decision.

[sugarme]

Thanks for your clarification and it's great that you are looking ahead. Lovely to try this lib out. Cheers.