-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enum support in base #3080
Comments
The simplicity of the current thing is great. I would only bring up a couple additional possibilities:
one new feature: a Other possible features:
|
What if you wanted the symbols to be scoped? Something like module bar
export bar
@enum bar a b c
end (Incidentally that doesn't seem to work: |
|
It's best if fixes to existing stuff are separated from new functionality that's up for debate. |
What are the plans for interoperability with C enums? This will useful to #2976. |
Cross referencing JuliaGraphics/Cairo.jl#11, as suggested by @timholy. As pointed in the mailing list, I wrote this as I was discovering the language, so there's a lot of room for improvement. I can't find the |
#2422 is the |
I missed enums at first but once I realized I could use any arbitrary |
Off the top of my head: checking that you pass a symbol that exists and is supported by the called method, ordering, C compatibility (and maybe type specialization?). |
@nalimilan raised a very important point. With enums "done right" it should only be possible to pass a valid enum value to a function that expects a certain enum. This would mean that an enum has an own type an is not only an Int. Still, not only for C compatibility, the values of an enum should be convertable to ints and vice versa. Converting an int to an enum should throw an exception if the value is invalid. Here is how an enum could look like if one integrates it into the language:
Certainly a switch statement would make this cleaner. |
One workaround I have used for C compatible enums is:
When using this in a module one has to export all values explicitly though. |
One better alternative for C compatible enums seems to be
Now one can simply export only The actual enum implementation should play nicely with the proposed switch statement #5410. |
Doesn't give type checks, unfortunately, but I like the simplicity. |
yes, this is not the ultimate solution. I would vote for an buildin language construct for this with the syntax
and |
See JuliaStats/DataArrays.jl#50 for a use case of enums with |
Another use case for this that I'm really looking forward to is representing Timezones as enum values. I think another great extension of having enums would be the ability to use them as type parameters (because they're just Ints, right?) It would be a nice way of allowing an enum value to be shown as the type parameter instead of just a 0,1,2, etc. |
Hi, @GenEnums begin
GLENUM
const GL_MAP1_GRID_SEGMENTS = 0x0DD1
const GL_COMPILE = 0x1300
const GL_SAMPLER_3D = 0x8B5F
const GL_QUERY = 0x82E3
const GL_INTENSITY = 0x8049
end This will create the following type: immutable GLENUM{T} <: Enum
number::T
name::Symbol
enumdict = enumdict #Generated dictionary with (uint32 => Symbol)
function GLENUM(number::T)
if !haskey(enumdict, number)
error("x is not a GLenum")
end
new(number, enumdict[number])
end
end Like this, if I get an GLenum anywhere, I can find out the corresponding name, to print out better error codes. @GenEnums begin
GLEnum begin
GLErrorEnum begin
const GL_NO_ERROR = 0
const GL_DEBUG_TYPE_ERROR = 0x824C
end
GLTypeEnum begin
GLFloatEnum begin
const GL_FLOAT_MAT2x4 = 0x8B66
const GL_FLOAT_VEC3 = 0x8B51
end
end
end
end |
It is not clear to me weather the |
No it doesn't, as it would be relatively troublesome for OpenGL. |
While the enum support that is talked about here certainly should play nice with C libraries I find it more important that it is useful in Julia as a language construct. And without scope you have to repeat the enum type name in the actual values (like the GL prefix). I think seeing all these different enum implementations it would be really really great to get support for enums in Julia base/core. |
Just to make sure that this is understood correctly, I'm not arguing for So you're suggesting something like GL.DEBUG.TYPE.ERROR, instead of 2014-07-07 19:48 GMT+02:00 Tobias Knopp [email protected]:
|
No I think your solution is just fine at this point. What I mean with "multiple levels" in Gtk is for instance So a C enum value usually encodes 3 things. A library name, the enum type and the enum value. In Gtk.jl all these enums are automatically created by the way. |
Having advocated for this, I'm taking a stab at implementing enums (based heavily on @vtjnash's work in #2988). I've also been reviewing Python's internal implementation of enum.Enum. @enum FRUIT apple=1, orange=2, kiwi=3
f(x::FRUIT) = "hey, i'm a fruit"
f(FRUIT(4)) # valid, even though we didn't define a FRUIT(4) Thoughts on this? |
This should be invalid. I like to use enums to ensure all cases are handled, and if there is an easy way to accidentally create invalid enums, this is thwarted. |
Is this valid?
even though 6 is not one of the enumeration values? |
I agree with @eschnett. FRUIT(6) should be invalid. |
So why give them numbers and convert to/from int? Don't leak the implementation :) The sets of bits passed to/from C functions in ints are different things to enums as @eschnett wants to use them, they shouldn't be the same concept. PS I'm not advocating for/against, just asking some questions to ensure that they are considered. |
The benefit of leaking the implementation is that it gives a direct way to translate things to C (and other languages, or storage systems that use integers for categorical values). It's also a great way to name some magic numbers that is used in calculations (eg. bitmasks, but arguably that could be a different concept from a enum). I just came to think of |
Closed by #10168 |
Currently enum.jl lives in extras. Since enums are generally considered useful, we should do a proper design pass on enums and add them to base. Part of #2422. For design inspiration, the PEP might be helpful: http://www.python.org/dev/peps/pep-0435/.
The text was updated successfully, but these errors were encountered: