3 ms·

Design by Contract isn't just asserts. The only thing that contracts and asserts have in common is that they are expressed as semantic predicates. DbC formaliz

Design by Contract isn't just asserts. The only thing that contracts and asserts have in common is that they are expressed as semantic predicates. DbC formalizes the idea of a contract (hence the name) between the caller and callee (in Eiffel parlance, the client and supplier of a service) and what each expects of the other and is part of the interface of a class. Accordingly, there are rules for contracts (visibility of symbols used in a contract must match the visibility of the function it is attached to, how contracts are related to each other via inheritance, etc.). It is not a terribly complicated concept, but it's also not just asserts.

gnaritas 11y ago
> Design by Contract isn't just asserts. That's exactly what it is, but it's a very specific style of asserts with very specific rules as to what and when to assert; it is however, still just a bunch of asserts.
- platz 11y ago
  yep!
- rbehrends 11y ago
  Okay, then explain to me how (say) in C++ you can annotate pure virtual methods with contracts or how inheritance of contracts can be done in C++, assuming you want to implement them using asserts. For that matter, how do you implement class invariants, which need to be checked before and after each qualified call to an instance of the class, but not when the call is unqualified? The other essential part that asserts don't really capture is that contracts (as pre- and postconditions) are part of the API, while asserts are part of the implementation.
  - gnaritas 11y ago
    > in C++ You can't blame me because some language you choose has limited meta abilities and doesn't allow you to place asserts anywhere. An assert is a generic concept that you can do in any language, and in languages with meta-facalities all of that is trivial to do, you're too focused on "where" the assert is in your specific language, but DBC came from Eiffel, not C++, and checking conditions or blowing up is an assert no matter where it occurs. DBC is cool, the places DBC chooses to do it's asserts are also a big part of what DBC is, but it's still all just some asserts in creative places under creative inheritance rules.
    - rbehrends 11y ago
      Well, if you are sufficiently fuzzy when it comes to equivalence, then every programming language is just about shuffling bits around registers and they're all one and the same thing. But in the end, interface (contracts) and implementation (asserts) aren't actually the same thing. Having commonalities is not the same thing as being the same.
      - gnaritas 11y ago
        Well I'm not going to argue about it, but I agree with OP, they're just asserts used in an idiomatic way.

gnaritas 11y ago

> Design by Contract isn't just asserts. That's exactly what it is, but it's a very specific style of asserts with very specific rules as to what and when to assert; it is however, still just a bunch of asserts.

platz 11y ago
yep!
rbehrends 11y ago
Okay, then explain to me how (say) in C++ you can annotate pure virtual methods with contracts or how inheritance of contracts can be done in C++, assuming you want to implement them using asserts. For that matter, how do you implement class invariants, which need to be checked before and after each qualified call to an instance of the class, but not when the call is unqualified? The other essential part that asserts don't really capture is that contracts (as pre- and postconditions) are part of the API, while asserts are part of the implementation.
- gnaritas 11y ago
  > in C++ You can't blame me because some language you choose has limited meta abilities and doesn't allow you to place asserts anywhere. An assert is a generic concept that you can do in any language, and in languages with meta-facalities all of that is trivial to do, you're too focused on "where" the assert is in your specific language, but DBC came from Eiffel, not C++, and checking conditions or blowing up is an assert no matter where it occurs. DBC is cool, the places DBC chooses to do it's asserts are also a big part of what DBC is, but it's still all just some asserts in creative places under creative inheritance rules.
  - rbehrends 11y ago
    Well, if you are sufficiently fuzzy when it comes to equivalence, then every programming language is just about shuffling bits around registers and they're all one and the same thing. But in the end, interface (contracts) and implementation (asserts) aren't actually the same thing. Having commonalities is not the same thing as being the same.
    - gnaritas 11y ago
      Well I'm not going to argue about it, but I agree with OP, they're just asserts used in an idiomatic way.