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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost