Yeah, I pretty much agree with all of this. Once field access is
overloadable, we can just create a Direction type and define
(automatically) the following methods:
getfield(::Type{Direction}, ::Field{:NORTH}) = Direction(0)
getfield(::Type{Direction}, ::Field{:EAST}) = Direction(1)
getfield(::Type{Direction}, ::Field{:WEST}) = Direction(2)
getfield(::Type{Direction}, ::Field{:SOUTH}) = Direction(3)
That would make Direction simultaneously a type and let it act like a
"namespace" in the sense that you can do Direction.NORTH and get the value
Direction(0). The definition of the type would be something like this:
immutable Direction
value::Cint
end
So that the values are completely memory compatible with C enums. Not sure
if we need a new keyword for this – especially considering that we'll want
something very similar for flags – i.e. enums where the values are powers
of two. Having @enum and @flag macros may well be enough. But this
definitely needs the ability to overload field access to make it work
completely naturally.
On Wed, Feb 19, 2014 at 3:17 AM, Tobias Knopp
<[email protected]>wrote:
> Yes it would be nice if it would be its own type and if we would have an
> abstract type "Enum" that the concrete enums subclass from. An enum should
> be further
> compatible with Cint and not only through conversions but also when be
> used as field type (to ensure compatibility with C structs).
>
> I further think that it would be worth introducing the "enum" keyword:
>
> enum Direction
> NORTH = 0
> EAST = 1
> WEST = 2
> SOUTH = 3
> end
>
> But unfortunatly I have zero scheme/parser knowledge so that I can't come
> up with a PR. Still IMHO its important to get a decision on enums rather
> quickly as they
> are needed and actually used in packages (e.g. in Gtk.jl).
>
>
