5 days ago
On 18/02/2025 1:16 PM, Element Green wrote:
> I got another request for making the names lower case.  I guess that would be **snake_case** for the modules and just lowercase for the package names?  So for example `pangocairo.font_map.FontMap` would be the `package.module.class`.  I'm considering making these changes, since it was only recently released and I have the version < 1.0 for a reason.  I must admit though that I prefer CamelCase but understand the reasons for using lowercase packages and modules (for case insensitive file systems).

If you are generating these modules, and its coming from the source material, stick with the source material for names.

Otherwise you could get conflicts at a later point in time (not good).

5 days ago
On Tuesday, 18 February 2025 at 00:30:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 18/02/2025 1:16 PM, Element Green wrote:
>> I got another request for making the names lower case.  I guess that would be **snake_case** for the modules and just lowercase for the package names?  So for example `pangocairo.font_map.FontMap` would be the `package.module.class`.  I'm considering making these changes, since it was only recently released and I have the version < 1.0 for a reason.  I must admit though that I prefer CamelCase but understand the reasons for using lowercase packages and modules (for case insensitive file systems).
>
> If you are generating these modules, and its coming from the source material, stick with the source material for names.
>
> Otherwise you could get conflicts at a later point in time (not good).

Well its GObject Introspection which is flexible with respect to how languages utilize it for creating language bindings.  It is encouraged to utilize it in a way that feels native from what I understand.  It seems like most languages use TitleCase for namespaces and class names, but snake_case for function names.  This includes Python, C++, and Rust from what I can tell.  This matches what is in the GIR files.

At the moment giD matches this, other than I'm using camelCase for function/method/enum value names instead of snake_case.

I like it how it is, but I want to make sure it isn't too offensive to D programmers ;-)
4 days ago

On Tuesday, 18 February 2025 at 00:16:40 UTC, Element Green wrote:

>

On Monday, 17 February 2025 at 11:32:06 UTC, Dejan Lekic wrote:

>

Amazing! The only thing I do not like is that module/package names are upper-case, but GtkD does the same so it should be easier to move to gid/gidgen if it turns to be equally good...

I got another request for making the names lower case. I guess that would be snake_case for the modules and just lowercase for the package names? So for example pangocairo.font_map.FontMap would be the package.module.class.

First off: Cool project!

About names: Indeed, this is what the language spec has to say about module names (https://dlang.org/spec/module.html):

>

By convention, package and module names are all lower case. This is because these names have a one-to-one correspondence with the operating system's directory and file names, and many file systems are not case sensitive. Using all lower case package and module names will avoid or minimize problems when moving projects between dissimilar file systems.

Cheers,
Bastiaan.

2 days ago

On Sunday, 16 February 2025 at 19:26:24 UTC, Element Green wrote:

>

giD (pronounced giddy) is a repository for GObject Introspection D binding libraries. Current focus has been on adding the Gtk4 graphics toolkit and dependencies with the goal of adding all libraries with GObject Introspection API descriptions which are of interest (any of these from the Python PyGObject project for example).

This is great!

1 day ago

On Wednesday, 19 February 2025 at 11:14:51 UTC, Bastiaan Veelo wrote:

>

About names: Indeed, this is what the language spec has to say about module names (https://dlang.org/spec/module.html):

>

By convention, package and module names are all lower case. This is because these names have a one-to-one correspondence with the operating system's directory and file names, and many file systems are not case sensitive. Using all lower case package and module names will avoid or minimize problems when moving projects between dissimilar file systems.

Perfect! Just the clarification we needed. Thanks!

1 2
Next ›   Last »