|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2005-06-30 18:06:06
Arkadiy Vertleyb wrote:
> "christopher diggins" <cdiggins_at_[hidden]> wrote
>
>
>>"Arkadiy Vertleyb" <vertleyb_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk