On Mon, Jun 6, 2011 at 9:02 AM, Derek Atkins <warl...@mit.edu> wrote:
> Christian Stimming <christ...@cstimming.de> writes:
>
>> But in general: I don't see the value of those macros here anyway. I
>> mean, the list of enum values need to appear in the definition of
>> LOG_LEVEL_LIST anyway. Passing this list through two other macros
>> doesn't really save any typing except for the two words "typedef enum
>> { ... }". The macros might have made a little bit of sense if it were
>> for a unified generation of some wrapper function (e.g. the conversion
>> functions from and to string)... oh, I see: Some of the enum
>> declaration actually use those: AS_STRING_DEC, AS_STRING_FUNC,
>> FROM_STRING_DEC, FROM_STRING_FUNC.
>
> Yes, there is value to make sure that you only have to make changes in
> one place.
>
>> It's a classical tradeoff between saving of typing and making the code
>> less readable: IMHO it is a big disadvantage that those functions are
>> hidden behind this non-understandable macros. Because of that, I would
>> rather prefer writing all the declaration and also those conversion
>> functions in plain text instead of hiding them behind macros.
>
> This "macro maze" was done to make it easier to maintain the list of
> macros. Before, if you added a macro you had to make changes in
> about three or four places! Now you only need to make changes in one
> place and it all just works. The idea here is that you can define the
> enumerator and it automatically creates the enum->string and
> string->enum functions for you.
>
The problem here is that it creates improperly formed code, so the
question is whether this issue can/should be fixed somehow within the
qofutil macros, or by simply swapping the comma separators out of
ENUM_BODY and into the definitions of the typedefs such as the
LOG_LEVEL_LIST(_) suggestion above, or another solution. Looking at
the code some more, I think swapping the commas outright would break
the other conversion functions.
Based on your feedback I have the impression that simply eliminating
DEFINE_ENUM might not be the best approach and I will keep looking for
a better solution; however, at minimum any enums which are defined
using DEFINE_ENUM could instead be explicitly defined if they do _not_
use the other conversion functions.
I will need to think about the macros some more to see if there is a
better way to get properly formed code from DEFINE_ENUM, while
maintaining compatibility with the other conversion functions.
Thanks,
-Tim
>> But in any case, those enums which don't use the conversion functions also
>> don't need to use the DEFINE_ENUM macro. Hence, feel free to submit a patch
>> that replaces DEFINE_ENUM by a normal declaration for all enums which don't
>> use the conversion function macros. Thanks!
>
> Sure, if you *never* use the conversion functions then yes, I feel you
> can use a regular enum instead of the DEFINE_ENUM macro.
>
>> Christian
>
> -derek
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warl...@mit.edu PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
