Hi All,

Is there a namespace I should implement in Raylib? For example, I cannot compile without writing Colors at the beginning of the colors: Colors.GRAY

SDB@79

On Monday, 28 February 2022 at 11:48:59 UTC, Salih Dincer wrote:

Assuming you mean the raylib-d binding, it implements the values as a named enum, so the Colors namespace is required.

https://dlang.org/spec/enum.html#named_enums

If you have a situation where you need to type it multiple times in consecutive code lines, you can use with:

with(Colors) {

}

Then you can drop the namespace and just used the values. Very useful for switches:

with(Colors) switch(myColor) {

}

You can also generate aliases, so that e.g., LIGHTGRAY is equivalent to Colors.LIGHTGRAY). Just throw this template function in an appropriate module:

enum expandEnum(EnumType, string fqnEnumType = EnumType.stringof) = (){
    string expandEnum;
    foreach(m;__traits(allMembers, EnumType)) {
        expandEnum ~= "alias " ~ m ~ " = " ~ fqnEnumType ~ "." ~ m ~ ";";
    }
    return expandEnum;
}();

Then you can mixin aliases for any named enum members you'd like:

mixin(expandEnum!Colors);

On Monday, 28 February 2022 at 11:48:59 UTC, Salih Dincer wrote:

When writing C bindings, you may refer to this:
https://p0nce.github.io/d-idioms/#Porting-from-C-gotchas

This keeps example code working.

On Monday, 28 February 2022 at 12:18:37 UTC, Mike Parker wrote:

enum expandEnum(EnumType, string fqnEnumType = EnumType.stringof) = (){
    string expandEnum;
    foreach(m;__traits(allMembers, EnumType)) {
        expandEnum ~= "alias " ~ m ~ " = " ~ fqnEnumType ~ "." ~ m ~ ";";
    }
    return expandEnum;
}();

mixin(expandEnum!Colors);

It definitely works, thank you.

On 2/28/22 6:48 AM, Salih Dincer wrote:

If you refer to raylib-d, that's how it was since I've ever used it.

The original C code uses #defines for all the colors. It's an interesting incompatibility issue:

1. C doesn't support enums of anything but ints
2. D doesn't support #define constants

I think this is the only reason the colors are not an enum in the C code in the first place.

One way to fix this would be to just use individual enums to the raylib-d binding. I think it might have been this way originally.

I'm hesitant to change it, but I might define both at some point.

In general, the raylib enumerations are overly verbose for D, e.g. KeyboardKey.KEY_X, instead of just KeyboardKey.X. I'd love to provide "better enums".

-Steve

On Tuesday, 1 March 2022 at 02:42:52 UTC, Steven Schveighoffer wrote:

In Derelict, I exclusively used anonymous enums with an alias to the base type like Guillaume noted above. When I did bindbc-sdl, I decided to go with named enums + the template I pasted above---I put the mixin at the bottom of each enum declaration. Though I do use anonymous enums now for any that are intended to be used as bit flags.

The mixin approach allows you to keep the stronger typing of named enums and still maintain one-to-one compatibility with the with the C source if both are important to you. I'm ambivalent about it now.

If the type is Color I think the compiler should allow GRAY if it is a member of Color, isn't how strong statically typed language should work? I wonder what is the rational against it? How hard would it be to allow it?

On 3/1/22 7:22 AM, meta wrote:

The problem is how the original source works.

The only way to define a manifest constant for a struct instance in C is to #define it.

So I'm sure that if raylib could put that inside the Color type it would, but it can't.

What a D binding should do is exactly what Mike said -- provide a complete binding as expected, and then add machine-generated nicer APIs.

I actually have an open issue, in case anyone is interested in working on it: https://github.com/schveiguy/raylib-d/issues/8

-Steve

On Tuesday, 1 March 2022 at 12:29:56 UTC, Steven Schveighoffer wrote:

Oh I was talking with regard to D's enum, not about the binding, allowing it via D, would make interfacing with C code easier

enum Color
{ GRAY }

void setColor(Color color);

setColor(GRAY);

On Tuesday, 1 March 2022 at 13:15:09 UTC, meta wrote:

enum Color
{ GRAY }

void setColor(Color color);

setColor(GRAY);

Then that defeats the purpose of having named enums.