[boost] Re: enable_if review

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-10-11 08:39:09

David B. Held wrote:
> "Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
> news:bm63j5$b0g$1_at_sea.gmane.org...
> First of all, my vote is to accept enable_if.
> 
> 
>>[...]
>>While this is necessary for the MPL itself, it puts a price on
>>other components.
> 
> Or maybe it adds value to other components, since working
> with MPL gives you more out-of-the-box stuff to do with them.

Of course, I don't doubt the benefits of MPL. When you need it, it's a 
wonderful tool to have.

>>It depends on conventions others have to fulfill. The
>>implementation and documentation of enable_if is much
>>larger than what it would probably be without the MPL.
> 
> But is that really a bad thing?  std::sort() is much more
> complicated than it would be without the STL.  Abstraction
> has its price, but we pay it because of the reward.

Maybe I'm nitpicking now, but from MPLs POV, the naming convention is to 
use _c for the "special" case that you want to provide the value 
directly. But I wonder if this was a good choice as it seems to me that 
from an outside perspective, it would make more sense to add a _t the 
MPL-version of the general part. This would IMHO be more consistent and 
remove the small price for people that use enable_if without caring 
about the MPL. But that is actually the smallest issue, I think the 
separation of components (with separate documentation!) is much more 
important. Having template-traits is nice, but when they are hidden 
inside MPL and not documented, they are close to useless for me. Look at 
the history of enable_if: It was developed several times independently 
IIUC and just now we are giving it the attention it deserves as a 
valuable technique on it's own. I'm in no way against the MPL, I just 
would like to make people think about factoring out components. My 
experience is, that it's these little helpers that are often more needed 
than large libraries and frameworks in my job. It's also easier to 
convince your boss that you need a small tool like enable_if instead of 
the whole MPL, YMMV.

> Well, there is a danger in letting MPL become the Borg.
> On the one hand, we should seek to refactor stuff that doesn't
> need to be in MPL into independent libraries that can be
> used on their own.  Which means that if traits could all be
> moved to the type traits library, I don't see why they shouldn't.

Exactly. As Dave also mentioned: type-traits and tuples are also good 
examples for things that would well be seen as MPL components, but that 
are currently (and luckily) independent from the outside perspective. 
Whether or not they use some parts of the MPL (which uses the 
Preprocessor Library, which uses...) is another story.

> The problem is that MPL is kinda like an RTL for the compile-
> time world.  It provides a lot of fundamental services that
> other meta-stuff can use, which is also part of its purpose.
> So maybe people who want to do a lot of meta-stuff will just
> have to get used to it in the way we are used to linking to an
> RTL every time we build a program.

As I said, I don't mind the dependency. I just think that we should have 
separate and independent documentation of some parts...

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de