On 9/3/04 6:03 PM, Larry Wall wrote: > On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote: > : Synopsis 4 says: > : > : "PRE and POST must return boolean values that are evaluated according to the > : usual Design by Contract rules." > : > : Do "the usual Design by Contract rules" include the ability to "turn off" > : (i.e. remove from program flow) PRE and POST blocks for performance reasons > : in production, or is than an anathema to the DBC crowd? :) > : > : I know you can do debug-assertions-like things with macros, but then you > : have to decide how expensive your pre/post checks are. The very expensive > : checks have to go into macros that you can "turn off" in production. But > : the cheaper stuff can stay in PRE/POST blocks (assuming they can't be turned > : off). Seems like an odd split...or am I over/under-thinking this? > > I don't see how we could prevent someone from clobbering the global > definitions of PRE and POST to be no-ops if they wanted to. Seems to > me that the whole point of putting the program in charge of its own > compilation is to let it be in charge of its own compilation, n'est pa?
Hm, okay, but there'd still be the "call" (or whatever) to the overridden versions. I guess that is "no-op"ing them, but they're still technically in the program flow, unlike "disappearing macros" or #defines in C or whatever. Any facility for totally nuking them? -John
