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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-02-15 22:58:42

Daniel Frey wrote:
> >> I won't try to fix any of these anymore. I neither understand the
> >> documentation nor the implementation of boost's type-traits. I 
> >> tried to make the code better but AFAICS there is no interest in 
> >> improvment.
> > 
> > Does anyone understand what improvement you're trying to make?
> 
> I have the impression that the type-traits can and should be 
> improved. I don't have a complete solution for everything at once 
> and I prefer evolution over revolution. Thus I tried to start by 
> suggesting a new is_class implementation. I was disappointed to see
> only bashing on details instead of a discussion of the "big picture".

What is a "big picture" here? Looking at your original posting, it's all
seems to be about the details. 

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 start the
discussion by posting an incomplete and large enough amount of code be
ignored by most of the skimming readers, and leave it to the library
maintainers to figure out what they can take out of it, if anything, there
is a huge possibility that it will progress in the way it did in this case.
I don't think there is anything wrong with it. If you want a different kind
of discussion, try a different approach. E.g. post a drop-in replacement for
'is_class', motivate why it is better, and I am sure John will happily
accept it.

> The basic point was (IMHO) never answered. 

That is ...?

> I tried to clean up the implementation by providing a closed 
> implementation of is_class for more compilers. This should decrease 
> the coupling of all the different parts. I think that this is a 
> better design than the current one. The example I gave which I 
> thought might show the local problem was wrong. My fault, granted. 
> But does it speak against cleaning up the code?

No, it doesn't. But, in general, you cannot expect the maintainers to follow
through the course of your experiments, however interesting those are. They
might sometimes, when they have resources, but if you want the concrete
results, try to post the concrete (and, if it's possible, complete)
proposals.

> 
> 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 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!

> 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.

HTH,
Aleksey