Despite the several benefits of contracts seen earlier, their use is not widespread yet. Most libraries still do not express any contract at all . Are there some “closet contracts ” lurking under the cover anyway — even if the underlying language and method does not support them — in some other forms like remarks in the software documentation, or are contracts just an artifact of the Eiffel language? This is what Bertrand Meyer and I call the “Closet Contract Conjecture”. There have already been some publications about it: , , , and . THE CONTRACT WIZARD.NET libraries are interesting candidates to evaluate the relevance of the Closet Contract Conjecture because the flexibility of the.NET component model has enabled the development of a “Contract Wizard ” , a tool that enables a user to examine a compiled module (“assembly ” in.NET), typically coming from a contract-less language such as C#, Visual Basic, C++, Cobol etc., and interactively add contracts to its classes and routines, producing a proxy assembly that is contracted as if it had been written in Eiffel, but calls the original. The Contract Wizard relies on the reflection capabilities provided in.NET by the metadata that every assembly includes, providing interface information such as the signature of each routine, retained from the source code in the compiling process
To submit an update or takedown request for this paper, please submit an Update/Correction/Removal Request.