`scoped_enum`'s abuse of `get_property`

[luke-kiernan]

Running @snoop_invalidations on using PowerSimulations, I see the following:

 inserting getproperty(::Type{FACTSOperationModes}, sym::Symbol) @ PowerSystems.FACTSOperationModesModule ~/Documents/julia/Sienna/psy5/InfrastructureSystems.jl/src/utils/utils.jl:370 invalidated:
   backedges: 1: superseding getproperty(x::Type, f::Symbol) @ Base Base_compiler.jl:48 with MethodInstance for getproperty(::Type, ::Symbol) (1 children)
              2: superseding getproperty(x::Type, f::Symbol) @ Base Base_compiler.jl:48 with MethodInstance for getproperty(::DataType, ::Symbol) (387 children)
[repeats once for every scoped enum definition]

That second child has 387 invalidations. And that happens for every ScopedEnum! I'll see if I can find a way to quantify the pre-compilation impact of this...but at the very least, this is bad.

If we simply replaced ACBusTypes.REF with ACBusTypes._name2value[:REF], then it'd go away. Still, it'd be nice to have some more concise syntax. Maybe we could make something like ACBusTypes(REF) work.

[GabrielKS]

This does seem bad from a performance perspective (though agreed, let's actually quantify it in seconds before we're sure, I'm not very familiar with this sort of analysis). I don't think it's "abuse" of get_property, though? That does seem like the correct method to implement to get the syntactic sugar we're going for?

Removing dot access for scoped enums seems like an extremely, dealbreakingly breaking change, hopefully we can find a more performant implementation.

[GabrielKS]

This might also be a good time to revisit #289 or look into what other third-party enum packages might be available. See also my enum wishlist at #500.

[luke-kiernan]

CoPilot suggests defining them as constants, instead of as fields, but then we'd need to write ACBusTypesModule.REF not ACBusTypes.REF. Well, unless we can rename the module to the same thing as the enum, but I'd be surprised if Julia allows that.

Curiously, for ModelBuildStatus, we get more invalidations than for the other scoped enums: that one has a backedge with almost 30k children!

[odow]

So I'm starting to chase down compilation latency, and I came across this.

What's the goal of @scoped_enum? Why do you have it, and what is it trying to achieve?

Does it matter if you do:

# IS.@scoped_enum(COMPACT_PWL_STATUS, VALID = 1, INVALID = 2, UNDETERMINED = 3)
@enum(
    COMPACT_PWL_STATUS,
    COMPACT_PWL_STATUS_VALID = 1,
    COMPACT_PWL_STATUS_INVALID = 2,
    COMPACT_PWL_STATUS_UNDETERMINED = 3,
)

Then it's a one character change from COMPACT_PWL_STATUS.VALID to COMPACT_PWL_STATUS_VALID.

You can cast to and from Int.

julia> @enum(
           COMPACT_PWL_STATUS,
           COMPACT_PWL_STATUS_VALID = 1,
           COMPACT_PWL_STATUS_INVALID = 2,
           COMPACT_PWL_STATUS_UNDETERMINED = 3,
       )

julia> COMPACT_PWL_STATUS(1)
COMPACT_PWL_STATUS_VALID::COMPACT_PWL_STATUS = 1

julia> Int(x)
1

If we want to keep the current behaviour, I'll think about ways we could improve it.

One option is:

julia> struct CompactPWLStatus
           value::Int
       end

julia> struct CompactPWLStatusEnum
           VALID::CompactPWLStatus
           INVALID::CompactPWLStatus
           UNDETERMINED::CompactPWLStatus
       end

julia> const COMPACT_PWL_STATUS = CompactPWLStatusEnum(
           CompactPWLStatus(1),
           CompactPWLStatus(2),
           CompactPWLStatus(3),
       )
CompactPWLStatusEnum(CompactPWLStatus(1), CompactPWLStatus(2), CompactPWLStatus(3))

julia> COMPACT_PWL_STATUS.VALID
CompactPWLStatus(1)

julia> COMPACT_PWL_STATUS.INVALID
CompactPWLStatus(2)

julia> COMPACT_PWL_STATUS.UNDETERMINED
CompactPWLStatus(3)

[odow]

It's quite hard to estimate the impact of this, because there are so many and getproperty is a pretty basic method.

[luke-kiernan]

What's the goal of @scoped_enum? Why do you have it, and what is it trying to achieve?

I believe one of the goals here is to keep the global namespace clean, in case downstream things use the same generic names (FAILED, LONG). Another convenient thing about this implmentation is that "APPLE" and Fruit.APPLE are basically interchangeable.

AI suggests calling the module Fruit instead of FruitModule and defining instances like Fruit.APPLE as constants inside it. That'd make Fruit.APPLE work without the getproperty hack. (Apparently this is approach that EnumX.jl takes.) However, that'll break type naming. (Since the module is named Fruit, the enum type inside the module must be named something else: Fruit.T or Fruit.FruitType.)

[odow]

I guess that's the reason to prefix the full name of the enum before the value. So @enum(FRUIT, FRUIT_APPLE, FRUIT_BANANA) etc.

Changing either to Base.@enum or EnumX.@enumx is quite breaking throughout the ecosystem.