Arkadiy Vertleyb wrote:
"christopher diggins" <cdiggins@videotron.ca> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message
So why a solution that clearly involves repeating things multiple times is less ugly than a macro-based approach, that allows to avoid duplication?
He is entitled to his opinion, Arkadiy. Your comments are disparaging and disrespectful of his contribution.
I didn't mean to be disrespectful, and I don't think I was, but I do apologize if it sounded like this...
But I am also entitled to my opinion, and this opinion is that any solution that doesn't involve duplication is, by definition, cleaner than one that does. Firthermore, I do think that the goal of eliminating macros for the sake of eliminating macros is not a right goal. Therefore, while deeply respecting the author of this proposal, I simply think, based on his motivation, that this is a step in the wrong direction.
I replied to this, clicked the send button, and it vanished through thin air. I do not know why. Maybe it's early in the moring and I haven't had coffee yet :). If this is a duplicate, please pardon me. I have to re-write this again. The previous one can not be found in my sent box. Oh life!... No offense taken, Arkadiy. I understand your position. Please don't get me wrong. I am not against macros per se. I use macros all the time if it is the best solution for a given task at hand. I voted for FOR_EACH, for example. I believe it is the best solution given the limited tools we have at our disposal. For BIL, I am not quite sure. Here is my rationale: 1) Interfaces need to be immediately understandable. You read them all the time. It is a contract. By "immediately understandable", I mean something very close to plain C++ member function syntax. 2) Interfaces need to be documented. They need to be parsable by an automatic documentation extraction tool such as Doxygen or Synopsis. 3) You can have both. If you really insist on the macros, then there's no reason why you can't have them. actually, thinking about it now, there's a 4th one which is related to the implementation: 4) Introspection. The implementation allows you to inspect an interface if it has a particular member function and what it's return type and arguments are. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net