janderson a écrit :
> janderson wrote:
>> renoX wrote:
>>> Kevin Bealer a écrit :
>>>> == Quote from renoX (renosky@free.fr)'s article
>>>>> - why the name getString instead of the usual toString name?
>>>>
>>>> That could be changed too; I think of toString() as an object method, and
>>>> when adding a static method, I figured I should use a different name to
>>>> avoid conflicting with the method.  I didn't really check whether there
>>>> is a real conflict on this.
>>>
>>>  From my testing, it doesn't trigger a conflict, but I've only tested it inside one file.
>>>
>>>> There is kind of a strangeness with the way I defined this in that you
>>>> creating instances of the Enum!(...) struct is not useful.  The type is
>>>> only really interesting for its static properties.
>>>
>>> About this I was wondering if it wouldn't be less strange to do a template like this:
>>>
>>> // expected usage: DefEnum!("enum ListEnumFoo {A,B=1};")
>>
>> Advantage: you would be able to reuse the code as a sub-set of something else like serialization or another language that uses the same enum syntax.
>>
>> Disadvantage: Code is harder to understand.  Code runs slower.
> 
> Correction: The interpreter code is harder to understand.

Thanks for the correction, your initial remark was puzzling me.

That said why do you think the interpreter code is harder to understand?

In the template, the part printing the enum value is exactly the same as before with just two added (very simple) templates one to get the enum typename, another to get the enum body.

For some reason I've lost the code, I'll post it on Monday, but 90% of the code is still kevin bealer's code, so it doesn't look very different than before.

Regards,
renoX

> 
>>
>> -Joel
>>
>> -Joel

renoX wrote:
> Kevin Bealer a écrit :
>> == Quote from renoX (renosky@free.fr)'s article
>>> - why the name getString instead of the usual toString name?
>>
>> That could be changed too; I think of toString() as an object method, and
>> when adding a static method, I figured I should use a different name to
>> avoid conflicting with the method.  I didn't really check whether there
>> is a real conflict on this.
> 
>  From my testing, it doesn't trigger a conflict, but I've only tested it inside one file.
> 
>> There is kind of a strangeness with the way I defined this in that you
>> creating instances of the Enum!(...) struct is not useful.  The type is
>> only really interesting for its static properties.
> 
> About this I was wondering if it wouldn't be less strange to do a template like this:
> 
> // expected usage: DefEnum!("enum ListEnumFoo {A,B=1};")
> template DefEnum(char[] def_enum) {
> 
>     mixin(def_enum);
> 
>     static toString(EnumType!(def_enum) x)
>     {
>         // function body similar to the inital get_String()
>     }
> }
> 
> Advantages:
> -The reflective enum type is really an enum type, so it acts like one.
> -No weird struct.
> -When(If) I can convince Walther that writef("foo %s",x) means really writef("foo "~x.toString()); we could write:
> writef("enum x value is %d and name is %s\n",x,x); and have the correct result, because toString(ListEnumFoo x) would hide toString(int x) {x being an enum variable from type ListEnumFoo).
> 
> Disadvantage:
> No easy way to iterate among the enum values: we cannot do
> foreach(v; ListEnumFoo) because now ListEnumFoo is an enum not a struct..
> And we cannot pass an enum type as a parameter, other it would be easy to define function 'keys' and 'values' (like for associative arrays), so we'd need a dummy parameter, i.e you wouldn't be able to write
> foreach (v; ListEnumFoo) {} and
> neither foreach (v; ListEnumFoo.values()) {}
> but foreach (v; ListEnumFoo.A.values()) {} could perhaps work.
> 
> What do you think about this other way to do it?
> 
> Regards,
> renoX

I don't like the extra syntax -- in your example, the word 'enum' appears three times.  I also like the ability to foreach() over an enum. But this has made me think of another idea that adds some of the "enum"-ness back to the struct.  I'll post it if I can make it work.

Kevin