Aliaksei Syrel wrote > Hi > > Assertions play an important role in design by contract. It is great to > have assertions in Pharo out of box (Object>>#assert:). However in > projects > with many post- and precondition as also class invariants heavy usage of > assertions decreases performance... > > Would it be possible to have a compiler setting (in setting browser) to > enable/disable assertions and not compile them to bytecode? Compiler > should > ignore the whole assertion statement with removed condition. For example: > >> self assert: self hugeInvariant. > > with disabled assertion hugeInvariant must not be sent. > > Thanks, > Alex
My concern with this is that this proposal requires certain selectors to become /reserved/. Most SUnit variations that I have seen entail several dozen methods for asserting and denying behaviours, block evaluation versus inline expressions, descriptive explanations, and so on. It seems to me that you would be better off sending messages to a global. Instead of: > self assert: self hugeInvariant. have something like: > Assert that: self hugeInvariant. If the global Assert is bound to a stub the message is sent and ignored. If bound to a real assertion mechanism, it gets evaluated. Use blocks when the argument evaluation is expensive or expensive enough. > Assert evaluationOf: [self hugeInvariant]. None of the names should be taken as suggestions. Just the concept. This also offers the benefit that assertions are practical everywhere, not just under a TestCase hierarchy. A second order effect is you aren't playing with the compiler to turn it on and off, nor to extend the controlled API. -- View this message in context: http://forum.world.st/Disable-assertions-design-by-contract-tp4874499p4874621.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
