On Sat, 02 Jul 2011 01:39:38 +0000, Nathan Ridge wrote:
And my response is the same as always: the ease-of-use argument is a red herring. End user expectations are often misguided, and doing something wrong, on purpose, to fulfill those expectations is bad design and simply perpetuates misguided expectations. Input via pp-lib sequence is insignificantly different in terms of number of typed characters. The difference is typically two parentheses--one at the beginning and one at the end (", " is the same number of characters as ")(").
As a pp-lib user, I find it much more cumbersome to write "MY_MACRO((a)(b)(c))" than "MY_MACRO(a, b, c)" - primarily because the latter requires a lot less keyboard acrobatics - and I have written my own equivalent of VARIADIC_TO_SEQ to allow me to write the latter.
Keyboard acrobatics? I thought programmers were the last of the breed that could type all of those special characters without evening thinking about it. :) In any case, I'd bet that this has a lot more to do with familiarity (even muscle familiarity) than it does with acrobatics. I do both all of the time and because I'm used to both, the difference in keystrokes is irrelevant. Further, it is much easier to work with sequences in debugging contexts because it is easier to compose them and (slightly) easier remove elements (actually removing or via comments). E.g. #define A (1)(2)(3) #ifndef NDEBUG #define B (4)(5)(6) #else #define B #endif MY_MACRO(A B) What do you do with sequences of C++ types which may contain open commas? The bottom line is that MY_MACRO(a, b, c) does not scale to the general case. Neither does MY_MACRO((a, b, c)), though it gets closer (though not for C++ types). The pp-lib has to provide infrastructure to support the general case, not a bunch of highly specialized cases. Regards, Paul Mensonides