4 ms·

I worked on a large C++ project with design-by-contract pattern a long time ago. It was not the most pleasant experience. There was so much more code to validat

by taude 8y ago

I worked on a large C++ project with design-by-contract pattern a long time ago. It was not the most pleasant experience. There was so much more code to validate pre and post conditions and class invariants. It might have had a lot to do because it was a classic OO business system (think a large Java app now, but where all the code was C++), but I remember spending more time writing the contract code than the actual business code. Is there any recent writings on this pattern on applying the idea more sanely? As it is, I think I prefer to write testing code outside of the core behavior and have to anticipate what values are valid, or create new tests as bugs are found.

apaprocki 8y ago
Contracts were developed into the C++ standard to make this easier: https://en.cppreference.com/w/cpp/language/attributes/contract https://en.cppreference.com/w/cpp/language/attributes/contra...
fiddlerwoaroof 8y ago
I think in languages like Eiffel that have first-class support for DBC, there’s less noise because the language is designed to propagate contracts appropriately (e.g. making subclasses inherit contracts from their base classes.) Also, there’s been a lot of work in the Racket community on contracts: I think it has something to do with making Racket/Typed Racket interop safe .
throwawayjava 8y ago
There's a whole "paradigm" called "light weight verification". I could point to particular papers, but unfortunately I don't know of a good survey article or exemplar tool/implementation/framework. But the term is very google-able, and skimming papers/tool descriptions will quickly give you a general sense for what sort of things are possible.
macintux 8y ago
It definitely seems like any OOPL would be inherently at a severe disadvantage in this style. In most Erlang code all you’d have to check are the function parameters. One concern I have with their Erlang solution is that the preconditions and postconditions are expressed for the function as a whole, not each function clause. In some contexts, rather like OOP, a function can be quite different depending on the context it’s called with.

by taude 8y ago

apaprocki 8y ago

Contracts were developed into the C++ standard to make this easier: https://en.cppreference.com/w/cpp/language/attributes/contract https://en.cppreference.com/w/cpp/language/attributes/contra...

fiddlerwoaroof 8y ago

I think in languages like Eiffel that have first-class support for DBC, there’s less noise because the language is designed to propagate contracts appropriately (e.g. making subclasses inherit contracts from their base classes.) Also, there’s been a lot of work in the Racket community on contracts: I think it has something to do with making Racket/Typed Racket interop safe .

throwawayjava 8y ago

There's a whole "paradigm" called "light weight verification". I could point to particular papers, but unfortunately I don't know of a good survey article or exemplar tool/implementation/framework. But the term is very google-able, and skimming papers/tool descriptions will quickly give you a general sense for what sort of things are possible.

macintux 8y ago

It definitely seems like any OOPL would be inherently at a severe disadvantage in this style. In most Erlang code all you’d have to check are the function parameters. One concern I have with their Erlang solution is that the preconditions and postconditions are expressed for the function as a whole, not each function clause. In some contexts, rather like OOP, a function can be quite different depending on the context it’s called with.