[boost] RE: Re: Re: Re: is_class

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-02-16 05:10:42

On Sun, 16 Feb 2003 04:58:42 +0100, Aleksey Gurtovoy wrote:

> Daniel Frey wrote:
>
> [...]
>
> Anyway, I would understand your frustration if you've proposed a drop-in
> replacement for the current 'is_class' implementation that  passes all
> the current tests and is better, in at least one way, than what we have
> now - and it was ignored. But that's not what happened, is it? If you

I can't provide a drop-in replacement. I don't have all the compilers
needed. And decoupling of components is IMHO an improvement, whether you
can see a direct consequence of not. The type-traits depend on each other
in ways that I find hard to follow. I thus thought that I offer an
implementation that works for some compiler and the maintainer would then
try to verify it and integrate it. Given that there are several levels of
indirection in the current implementations there must be some important
reasons for it, but I can't see it. The philosophy so far seems to be
"never change a running system". Either I show a complete implementation
for all compilers which has a direct improvement for the user or nothing
will be changed. I think that this is one of the reasons for
unmaintainable code.

>> As far as I learned right now, boost is not meant to provide a clean
>> implementation, instead, it provides a good documentation and an
>> implementation that "just works".
> 
> That's just not true. When possible, we do strike for a clean
> implementation. It's the sorry state of current compilers that often
> forces one to sacrifice the internal beauty for usefulness in the real
> world.

But the current state IMHO suffers from these "real world" compilers as it
contains large amounts of work-arounds. The main problem for me as a
reader of this code is the lack of documentation of how I can still work
on this code.

And for the "That's just not true"-part, may I refer you to Dave A.'s
words:

"Are you saying we need more implementation-level documentation?  Most
projects concentrate on that at the expense of user-level docs, and it
hurts usability.  Boost's focus goes the other way, which probably hurts
transparency."

(He said that in a different thread to me, but this is why I think what I
think)

>> But even the documentation confused me several times. is_scalar doesn't
>> mention enum, is_member_function_pointer is not a secondary type
>> category,
> 
> Patches are always welcome!

If we agree it should be fixed, I can even change it in CVS directly - but
I won't do this without John's OK.

>> the mixture of utility functions and a framework and primary type
>> categories are implemented using secondary type categories. Even if it
>> works, it is IMHO still bad code.
> 
> If you have a vision of how to improve it, the best way to change the
> status quo is to post a proof in the form of working code.

My "vision" is to do it step-by-step and with the help from others. I
neither have the time nor the amount of compilers needed to do everything
on my own and in one big step. Or are you suggesting that boost can only
be improved by people that have access to all compilers that boost
supports? Than I guess you rule out most of the boosters immediately.

Regards, Daniel