https://github.com/JuliaLang/julia/pull/2988
I essentially wrote an `@flags` macro in that pull request. Although
the @flags name is much better than whatever I called it originally.
1. Yes, but it perhaps best left up to the author of the module to do
the wrapping, for flexibility.
2. No. I don't think we need a macro to create types. If you really
want that, then just write it. The complete definition is pretty short
(assuming you want it to be parameterized by a number -- it's even
easier if you just want unique types).
type Foo{T}
Foo() = (isa(T,Int) && 1 <= T <= 10 ? new() : error("T must be an
integer between 1 and 10"))
end
const BAR = Foo{1}()
const SPAM = Foo{2}()
convert{I<:Integer,T}(::Type{I}, ::Foo{T}) = convert(I,T)
convert{T<:Foo}(::Type{T}, i::Integer) = Foo{convert(Int,i)}()
function show(io::IO, foo::Foo)
print("Foo.")
if foo == BAR; print(io, "BAR")
elseif foo == SPAM; println(io, "SPAM")
else
error("unexpected, invalid Foo")
end
end
I think enums are typically useful for places where you don't want to
dispatch on the value. Types are better when you want to dispatch (and
where the enum doesn't have/need an associated number).
On Thu, Dec 26, 2013 at 4:39 PM, Stefan Karpinski <[email protected]> wrote:
> There is no @flags macro but it would be pretty easy to write, analogous to
> @enum.
>
> The real questions to me here are:
>
> Should these be defined in a module so that they are Foo.BAR, etc.?
> Should it by default be possible to dispatch on each value? I.e. should Foo
> be a parametric type and should BAR be the unique instance of Foo{0}?
>
>
>
> On Thu, Dec 26, 2013 at 4:36 PM, Stefan Karpinski <[email protected]>
> wrote:
>>
>> It's pretty simple:
>>
>> julia> include("examples/enum.jl")
>>
>> julia> @enum Foo BAR BAZ QUX
>>
>> julia> Foo
>> Foo (constructor with 1 method)
>>
>> julia> BAR
>> BAR
>>
>> julia> BAZ
>> BAZ
>>
>> julia> QUX
>> QUX
>>
>> julia> isa(BAR,Foo)
>> true
>>
>> julia> isa(BAZ,Foo)
>> true
>>
>>
>> Foo is a type and BAR BAZ and QUX are constants bound to instances of it.
>>
>>
>> On Thu, Dec 26, 2013 at 4:26 PM, Marcus Urban <[email protected]> wrote:
>>>
>>> I don't quite understand how to use the @enum macro in examples/enum.jl.
>>> Could someone give an example that would have a similar effect to the C++
>>>
>>> enum class Fruit { Apple, Banana};
>>> auto f = Fruit::Apple;
>>>
>>> Also, there is the @flags macro provided?
>>>
>>>
>>>
>>> On Thursday, December 26, 2013 3:12:33 PM UTC-6, Stefan Karpinski wrote:
>>>>
>>>> That's a good approach if you're going to dispatch on the types, but if
>>>> they're just values, we really should have something more like an enum. At
>>>> this point, I'm thinking that @enum and @flags are good macros to have –
>>>> where the @enum macro just defaults to 0, 1, 2, etc. while @flags defaults
>>>> to 1, 2, 4, 8, etc. and defines bitwise operations on the flag values.
>>>>
>>>>
>>>> On Thu, Dec 26, 2013 at 8:13 AM, andrew cooke <[email protected]> wrote:
>>>>>
>>>>> great, thanks. a concrete example is just what i needed. andrew
>>>>>
>>>>>
>>>>> On Thursday, 26 December 2013 00:06:07 UTC-3, Kevin Squire wrote:
>>>>>>
>>>>>> The julia sort code might provide some guidance. It follows your last
>>>>>> proposal, having an abstract type Algorithm, and a number of concrete,
>>>>>> empty
>>>>>> Algorithm subtypes (QuickSort, MergeSort, etc.), plus exactly one global
>>>>>> constant instance of each of these subtypes. So, as you suggested,
>>>>>> there is
>>>>>> a little bit of setup overhead, but it allows you to use the "value" of
>>>>>> the
>>>>>> global constants for dispatch.
>>>>>>
>>>>>> Kevin
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 25, 2013 at 4:45 PM, andrew cooke <[email protected]>
>>>>>> wrote:
>>>>>>>
>>>>>>> I want to parametrize some code, so that it does one of three
>>>>>>> different things, depending on the "value" of a parameter. The
>>>>>>> parameter is
>>>>>>> purely symbolic - there's no corresponding numerical value.
>>>>>>>
>>>>>>> There's an enum.jl in examples and also some discussion of related
>>>>>>> ideas in issues. But this isn't (yet) in the language, and anyway it
>>>>>>> seems
>>>>>>> crude (these are symbols, not numbers).
>>>>>>>
>>>>>>> There's also the possibility of using an abstract type and then three
>>>>>>> concrete subtypes. That seems like too much work but, as far as I can
>>>>>>> tell,
>>>>>>> is the way to "do" algebraic types in Julia (see list.jl example).
>>>>>>>
>>>>>>> I guess I am overthinking this. But what is the right approach?
>>>>>>>
>>>>>>> Thanks, Andrew
>>>>>>
>>>>>>
>>>>
>>
>
