Enum:GetEnums() is a new function that returns a list of all Enums. This can be used to enumerate over all Enums. Example:
local eenumCount = 0
for _, enum in pairs(Enum:GetEnums()) do
if string.sub(tostring(enum), 1, 1):lower() == "e" then
print(enum)
eenumCount = eenumCount + 1
end
end
print("There are " ..eenumCount.. " Enums starting with the letter E!")
Which would print the following:
Enum.EasingDirection
Enum.EasingStyle
Enum.EnviromentalPhysicsThrottle
Enum.ErrorReporting
Enum.ExplosionType
There are 5 Enums starting with the letter E!
EnumItem.EnumType returns the parent Enum of an EnumItem. This can be useful if you want to check if an EnumItem is of a certain type.
game:GetService("ReplicatedStorage").RemoteFunction.OnServerInvoke = function(player, value)
if typeof(value) == "EnumItem" and value.EnumType == Enum.HumanoidDisplayDistanceType then
-- the player passed up the correct value type
return true
end
end)
The only thing I don’t like about custom Enums (or at least ones that you could add to the Enum global) is that there is the problem of potential conflicts with ROBLOX-created Enums in the future. Any ideas on how we would solve this?
Just don’t allow developers to overwrite official enums (obviously) and generate an error.
If they use a name that wasn’t taken but is now, then sadly enough their psycic powers broke their code.
Can’t we already create custom-enums sort-of though?
I would add some kind of service to the game hierarchy (or some kind of special object) in which you can set your custom enumerators (which would then be added to Enum when you run the file), and whenever you open the game file and you’re overwriting some existing enumerator, it can give a warning about it.
I think a special service/object would make sense because in this way, both the client and server knows about custom enumerators from the moment that they are run, so you can also pass the enumitems through remotes etc and they could still be recognised as such on the other end. (which is hard to do if you’re coding your own custom enumerator script, because you have to run them before any other code, and transferring them between client/server is non-trivial)
Scripts that run on other security levels could just ignore the changes made to the enumerator list.
There are billions of potential features we wouldn’t be able to get without using getfenv hax. Just because you can’t normally do it, doesn’t imply that it would be a useful thing to have. Requests for features that are more simply implemented in lua really rustle my jimmies
I’m with Tomarty on this, its a lot simpler when you just do something like this… not to mention assigning something as a Enum to the Enum library to use across different scripts without this module method is basically identical (on the surface) to setting a table value in _G… which is just a bad practice. This API would be better practice, but still just as annoying (if you’re like me and find _G annoying)
Integrating custom enums directly into the Roblox API isn’t going to work. It has all the same problems as using _G. It isn’t modular, and you wont avoid boilerplate.
Keep your enums next to the functions that need them. If those functions are provided by a module, then have it provide the enums as well.
Think of the Roblox API as being one giant module that has the privilege of being getfenv’d into all of your scripts. It uses its own enums all over its own API, and it provides references to them through the Enum object. It wouldn’t make sense to add custom enums here, because the Roblox API isn’t going to use them anywhere.
At most, there could be a feature that works like your Enum module. It would create custom enum objects that you can use in your scripts however you like. They would have no association with the built-in enums, they wont appear in the Enum global, and the Roblox API would have no real reason to be aware of them. But they’re available for your convenience. I imagine the CoreScript team would find this very useful with the Get/SetCore API.