I did a little thinking, and realized one of the big problems was in object construction, where I literally couldn’t use it. The old DBC-JS file had the approach of requiring users to call a separate function to execute the contract:
var root_3 = applyContract(getSquareRoot, this, 3); instead of
Ease of use beats functionality hands-down. Firefox taught us that for user interfaces, and this demonstrates the same for actual code. So obviously I had a design flaw in my design code.
To spare feedreaders from unwanted technobabble, I’ll continue the rest of this on a secondary page.
Observe the following function:
Note the getContractFunction actually returns a function, not an object or an ordinary value. If I have code like this:
Then the only call a user of sqrtObject has to make is
sqrtObject.sqrt(9). No applyContract() mess!
Suppose, though, you want your contract function to be a constructor. For that, the inner function of getContractFunction() is even simpler:
Contracts are thus simplified enormously. Here’s some sample code to demonstrate this new design-by-contract library:
Here’s the updated ecmaDebug.js file, with the new contract code. It also includes my custom NS_ASSERTION firing function for debugging purposes when Venkman just isn’t enough. Other features: toString and toSource have been redirected to the contract’s body (so you can see what the function’s really supposed to do). Also there is a toContractSource() and toContractString() which deliver the whole contract object in source and string form, respectively.