reflective enums

[renoX]

janderson a écrit :
> janderson wrote:
>> renoX wrote:
>>> Kevin Bealer a écrit :
>>>> == Quote from renoX (renosky at 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