It's only about 100 LOC, so that's probably a good idea. The code has been tweaked a little here and there, so we may want to wait a bit until it settles a little more.
-Jacob On Sun, Mar 1, 2015 at 9:06 AM, Uwe Fechner <[email protected]> wrote: > Is there a way to use the new @enum macro in Julia 0.3 projects? > Could it be added to Compat.jl? > > On Saturday, February 28, 2015 at 9:53:02 PM UTC+1, Jameson wrote: >> >> https://github.com/JuliaLang/julia/pull/10168 >> >> On Sat Feb 28 2015 at 3:45:31 PM Kirill Ignatiev <[email protected]> >> wrote: >> >>> There are libraries, like OpenGL, with very rich collections of enums. >>> In bindings to these libraries, the enums are used directly as integers, >>> with no special meaning attached to them, and the integers are passed >>> directly to the C functions. >>> >>> If you compare this with Haskell, for example, ( >>> https://hackage.haskell.org/package/OpenGL-2.11.0.0/docs/ >>> Graphics-Rendering-OpenGL-GL-BufferObjects.html), there enums are >>> transformed to Haskell type constructors, so it's no longer possible to >>> pass a wrong "kind" of enum to a C function. >>> >>> What's a good Julian way of specifying richer relationships between >>> plain C enums and their meaning? >>> >>> If symbols are the way to go, how would you write down a function that >>> takes a symbol as an argument, but only accepts a specific list of symbols? >>> Would you just use a Dict{Symbol, Cenum} to express the mapping between >>> Julia symbols and C enums? >>> >>> Do you think it's a good idea to replace C enums with "richer" Julia >>> values, when most users are probably just fine working with plain integers? >>> >>> This is an issue for most Julia bindings to C libraries, but it is >>> probably not very important because using plain enums doesn't lead to that >>> much trouble for anyone familiar with the underlying C library. >>> >>>
