Eliot Miranda-2 wrote > Hi Richard, > >> On Jan 28, 2016, at 2:15 PM, Richard Sargent <
> richard.sargent@ > > wrote: >> >> 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. > > It's a good concept, and is the object-oriented approach. It's just that > in practice the costs of creating blocks as assert: arguments, while > typically much cheaper than evaluating the assert and discarding its > result, are still significant > > Hence I'm open to a compiler hack that elides the assert: or deny: and > it's send altogether from the code. Open but not happy; it's something I > hold my nose to do. But this is a style I've been using for twenty odd > years and it is really nice to be able to write assert-laden code but not > have to pay in production. Thanks for the feedback, Eliot. It's appreciated. If we have to hack, I would rather see the hack done differently. One of my goals would be the ability to restore a production database into a test environment without having to recompile all the methods. (Some of our customers have systems with 30-40,000 classes!) To that end, I was wondering about hacking the compiler to test the association with the reference I've named Assert (but probably in a general approach for any name). The code generator would send a specific message to the currently bound value (one would require it to be implemented by all objects bound to the name, just for honesty and clarity), to ask whether the code generator should emit code to test the named receiver and skip the whole statement if it answers true. The code would be generated in all cases, but it would not be evaluated when the stub mechanism is associated with Assert, since it would answer true to the skip question. Likewise, the real assertion mechanism would answer false and the whole statement would be evaluated. That preceding paragraph glosses over a lot, but I hope the gist is sufficiently clear. > There is a ray of hope. The Sista adaptive optimiser /will/ be able to > elide all the cost of the block form: > > ... > self assert: [self expr]. > ... > > Foo methods for assertions > assert: aBlockOrBoolean > ^self > > because there are obviously no side effects. Whereas it will only be able > to elide the entire thing depending on expr in the non-block form: > > ... > self assert: self expr. > ... > > But I wonder how any people would have the discipline or insight to use > the block form. It looks unnecessarily verbose yes? > >> This also offers the benefit that assertions are practical everywhere, >> not >> just under a TestCase hierarchy. > > Whether asserts are practicable everywhere IME depend on how useful they > are in ongoing development. The fact that they cost a /lot/ and slow down > the VM simulator for Cog doesn't change the fact that it would be much > much slower to modify the code base. > > In another thread I was proposing to Gulle to use the VM simulator instead > of a custom VM for his Pharo bootstrap. But in that case one would /have/ > to find a way of eliding asserts. One approach would be a package-level > rewrite tool that could produce a copy of a package in which asserts have > been eliminated. One would always do development in the assert-laden > version, but could make the assert-less version available to clients who > treat the package as a black box, can therefore assume that no asserts > ever fail (because the asserts prove they don't) and use as > high-performance a version of the package as possible. > > With this approach there are no hacks in the compiler, although a > derivative of the compiler might be a workhorse in the rewrite from > assertful to assertless code. And the Monticello tools (& Metacello) > could help automate things. > > >> 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. >> -- View this message in context: http://forum.world.st/Disable-assertions-design-by-contract-tp4874499p4874896.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
