On Fri, 01 Jul 2005 06:50:36 +0800, Joel de Guzman wrote
Here's my rationale for the macro-less Interfaces:
1) An interface is supposed to be read a lot of times. It has to be immediately understandable to the human parser. It is not an implementation detail. It is a contract.
It's the human parser that's the real problem -- no question ;-) To quote myself from Feb of this year: "Also, I really hate macros for doing these sorts of things because I have to reverse engineer what the macro is doing when I need to read the code. At a minimum that means I need to go to another file, try and grok whether the macro applies to what I'm doing, mentally add in whatever functions/types it creates. I'm getting too old for these sorts of mental gymnastics -- I'd rather have the code just written out." http://lists.boost.org/boost/2005/02/21082.php I'd add to this that THE ALL CAPS STUFF IN CODE GETS REALLY TIRESOME TO READ MAKING CODE LOOK UGLY in my view. Of course macros don't technically "have to be all caps", but well they mostly are to prevent more serious problems.
2) I need one that can be parsable by a documentation extraction tool such as Doxygen and Synopsis. This is very important! Interfaces need to be documented.
These can be expanded before processing, although last I knew some debuggers have problems dealing with macros. Certainly tool vendors have said one reason they can't easily implement C++ tools (like say refactoring tools) is b/c of complications created by macros in C++.
3) You can have both! If you still insist on using macros, then by all means, use them.
Having the option is exactly the right approach -- when feasible. I'm really interested in Boost.Interfaces -- this looks like an incredibly cool design approach, but I, like you, would be put off by the need to use lots of macros in application code. So thx Joel! Jeff