Bit off-topic, but in C# at least you can mark your enums with the 'Flags' attribute to indicate it's a flags enum.

The odd thing here is that these don't seem to be flags.. can a glass be both shattered and shattering?

Maybe you read it wrong :)

See http://csharppad.com/

    // State flags
    enum EGlassRNState
    {
        EGlassRNState_Initial     = 0,
        EGlassRNState_Weakened    = 1 << 0,
        EGlassRNState_Shattering  = 1 << 1,
        EGlassRNState_Shattered   = 1 << 2,
        EGlassRNState_ActiveFrags = 1 << 3
    };
    foreach(var val in Enum.GetValues(typeof(EGlassRNState

))) { Console.WriteLine($"{val} -> {(int)val}"); }

Output:

    EGlassRNState_Initial -> 0
    EGlassRNState_Weakened -> 1
    EGlassRNState_Shattering -> 2
    EGlassRNState_Shattered -> 4
    EGlassRNState_ActiveFrags -> 8

I think he meant that in this context does not make sense for more than one value to be true at the same time , which is the reason you define enums this way, usually.

Not necessarily. Enums main application is to restrict a variable to a range of valid values. As to whether some other object may have one or more of these vales, enum makes no statement.

But then using bit fields makes no sense.

It can be used like this, no?

    writable = 001
    readable = 010
    readwrite = 011 (writable | readable)

Yes yes, but the point was, it can't be Shattering and Shattered at the same time ;)

I throw a baseball through a window, and set the window's state to both Shattered and Shattering. It's Shattered, for the purposes of "is this an intact pane of glass?" e.g. if I throw another baseball, it's not going to shatter again, and I can jump through it without any physical resistance (in the case of strong/thick glass, if it was still intact I might risk bouncing off if I'm at low velocity or mass).

But it's also still in the process of Shattering, so when I jump through it, I'm risking cuts, it's actively producing noise for someone to hear, that laser I'm shining at it will be fragmenting wildly rather than reflecting off/passing through/deflecting like it was before the glass started Shattering.

Ok, but it still doesn't make sense to use flags here, because according to your definition, a shattering window is always shattered.

Anyway, I don't think it's worth arguing design on this codebase because it is full of dirty things.

There are three distinct values: unshattered, shattering, and shattered which appear to correspond to 00, 01, and 10 with 11 being an unused state. This will always occur in boolean with 2 bits and 3 used values (unless someone stupidly gave it an undocumented purpose).

It could serve a dual function to describe what states are valid for a given piece of glass.

e.g.

EGlassRNState allowed = EGlassRNState_Initial | EGlassRNState_Shattered;

EGlassRNState current = EGlassRNState_Initial;

Time for a pull request? ;)