On Fri, 2004-12-31 at 18:17 -0500, Robert Shade wrote: > Just to add my two cents, I think I would discourage the attribute idea. > > For one, it would mean that your compiled application would have to link > with your DBC library. This would mean that the user would have to deal > with a bunch of #if's so that those attributes would not be compiled in > production code. Otherwise, the user would be forced to distribute your > library with their product.
Well, there wouldn't be a lot of #if statements, as far as I know. A failure of the preconditions indicates that there's a bug in your user's code. A failure of the postconditions or invariants indicates that a bug exists in your code. Because of this, there are really two use cases (although a bit more fine-grained tuning could be used without requiring you to be overly verbose). Firstly, debugging. You want everything on. That way, you can ensure that your code is working as expected. If any postconditions or invariants fail, you know that your code is not holding up its end of the bargain.. The second case is in release code. You want only preconditions on. The postcondition and invariant checks will probably be too slow to use in release code, and by that time you've already (theoretically) debugged your application. Unit testing combined with postconditions/invariants should discover a significant number of those bugs, and give you the confidence to disable them. Preconditions, however, would still be enabled. Since most functions already put lines in the beginning of functions anyways to test variable constraints, this would simply shift the placement of these tests from code to metadata. > Secondly, attributes would force the checking to be done by a modified > compiler. This would seriously limit your target audience to mono > folks. Love mono, but the masses are using Microsoft's compiler. Yeah =\ > An external tool would also allow you to investigate the code flow in > ways that the compiler may not. For example, you could do "process" > time checking of the code to see if your "contracts" are always > true/false. (I belive the MS compiler does this for conditionals) For > things that were marked "invariant", you could follow the code flow to > see if these are modified at any point. You'd perhaps even be able to > warn the user under exactly what conditions the contracts would fail. > If you had that functionality, you would completely eliminate the need > for the user to have the (runtime) contract checking code present. The > user would already know precisely under what conditions errors would > occur and could add exception handling to take care of it. I'm not quite sure if this kind of approach would work. Design By Contract explicitly states when contracts need to be checked, so having an external application that does process-time checking would be difficult to implement in this way. Also, preconditions are something you (almost) always want checked, so requiring a third-party application in this case seems even worse than a third-party library. Especially so, because any libraries which implement Design By Contract would then be forced to redistribute the application, and their clients would be forced to run it. In all, I want to avoid having to write a bottom-up parser for C#, or even rip out mcs' C# parser, and use it for my own needs. Is there some method of putting hooks into mcs, so that I don't have to modify the mcs code itself? -- Stephen Touset <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
