While adding Design-By-Contract (DBC) constructs to the language is a great idea, it is also quite dangerous as it can easily be misused. Moreover, one should really watch out how far DBC should be applied. As you probably know (assuming you wrote some Eiffel code), applying DBC as Bertrand actually meant it is great in theory but falls short in practice (it is not that easy and intuitive task to apply DBC correctly). So I would say that adding these constructs, although powerful, may eventually bring more hard than good (just look how easily people misuse the final keyword… yeah… a final setter.. thats a first for me). Further more, I do think that the final keyword has a place and can be used in scenarios where pre/post conditions (along with in/variants) cannot really help out. For example, providing some functional computation which cannot change by definition in order to implement a “correct” implementation. Yes, pre/post condition can help you assure in/variants states but sometimes you just don’t want the client of your code to even “play around” with some code. When used properly, within a well designed API, the final keyword should also not stand in the way of the “Opened/Closed Principle”. This is also the case where “interface oriented design” helps quite a bit.

Anyway, it’s a great and well written post which definitely makes you think… thanks.

Uri