> 2) pre&post conditions and class invariants have defined behaviour in cases > of inheritance, even/especially multiple inheritance. They are combined > non-trivially in subclasses. Without this I don't think you have DbC.
Yes, I forgot about that. Thanks. > Feel free to enlighten me about these obvious and extremely unsafe aspects of > Eiffel's type system. Personally, I can't say I ever noticed. Correct me if I'm wrong, but isn't it true that methods can be removed in subclasses? If that's not extreme, I don't know what is. >> 2) The "contracts" part does a very poor job. Instead of really improving >> the inherent unsafety, it resorts to testing. And… > > What constitutes a 'good' job? Well, a sound type system would certainly help. > 'Resorts' to testing. I have to admit to resorting to testing on occasion > myself. Frequent occasion. Routinely even. :-) You routinely try to overcome language weakness with tests? >> 2') ...not even the real, thorough testing — contracts system would be quite >> happy if the program works on the developer's machine. Which is the "works >> for me" approach certain languages gets rightfully blamed for. > > Really? You believe that automated testing and contracts are why software > bugs *are not* found? Is that what I said? I believe that testing means a lot more than just making sure the program works on the developer's computer. I believe that system that encourages the "works for me" approach is one of the reasons software bugs are not found. >>> Seems to me you're ignoring everything that happens between an empty >>> directory and a working program. Contracts help in that process (I say but >>> can't prove). >> >> I agree. They do help — but there are lots of things that help in this >> transition. Versioning systems. Collaboration tools. Bug tracking software. >> Text editors. Even debuggers. > > You should read OOSC2. You'll find that this is completely consistent with it. I've never said it's not. But all of these tools are external to the language, which means that they can be easily replaced if a better alternative surfaces. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
