-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Aaron W. LaFramboise
Of Aaron W. LaFramboise Wrote:
I've been thinking about Dave Abraham's suggestion <http://lists.boost.org/boost/2005/03/21839.php> that theres no reason to provide a special protection mechanism for these inner handles. The feeling I get from many here is that you should be able to hit a red button, such as including a special implementation header, and you're back in shoot-yourself-in-the-foot land, with the confidence that "the programmer knows what he's doing."
I've decided that this is not compelling for me. We always know what we're doing--we're superheroes, we're C++ programmers. Yet C++ is partly about letting us define a set of rules for ourselves, to catch our mistakes, and keep us honest. I think the ability to hit this red button and suddenly have full license to blow away a class's invariants without any of the traditional protection mechanisms is downright barbaric.
I think there *is* something special about inheritance. The "protected" keyword gets wonderful milage in other application domains, and I have no idea why system abstractions need to be any different, such that for system dependence, its perfectly acceptable to revert to pre-Dijkstraesque programming practices. Certainly noone would tolerate this additude with other well-defined standard libraries: no matter how much you beg, you just aren't going to get anyone to give you a
pointer
to std::list's linked list head. [Brian Braatz Writes:]
Weighing in. I am IN agreement with DaveA in the following "> David Abrahams wrote:
I have always thought that concrete implementations of portable libraries should supply users a way to get at the OS-specific data so
they can use platform-specific facilities on them if neccessary. " One of the problems of standardization of interface is that it HAS TO BE expandable and allow for future work to be piled on top of it.
In this case the best analogy I can provide is Microsoft Foundation Classes. Yes, yes, YES. I know it is evil in it's design. But one thing they was make it EASY for you to use "their" abstractions, but at the same time, allow for the programmer to decide they need to use a special API call. MFC is evil in many ways, but it has lasted a VERY long time and there are many applications written with it. I personally believe this is largely due to the notion that they ALLOW me to get to the underlying handle. This way, when the OS gets the ability to allow me to BLT semi-transparent gradient images, I can USE this in MFC, even though they never designed this model into it. While It is easy to argue MFC is mentally deficient in its design, I believe this one trait has given it utility and longevity. With THREADING- I believe the following: Moore's law is dead. Multi-core is where the HW folks are headed. The OS vendors, will naturally begin to add more API functions giving me more bells and whistles to play with in the threading world. Without access to the underlying handle, a threading library will not be quite as useful in "the real world" where I MIGHT need to take the plunge and hook up to some OS specific (or HW specific) concept. We must think about threading (and many other types of standard interfaces) as the FOUNDATION of further thinking. NOT the "final" design in the domain. :)