On 26/02/2016 12:30, Alexandre Bergel wrote:
I still do not understand. I would imagine something like:
foo
<precondition: #invariant>
<postcondition: #invariant>
self bar
But, all in all, what are we using pragmas here?
I can always do:
self assert: [ … ] description: …
Maybe we should specific a method called contractInvariant that is always
executed before and after. Using Reflectivity.
Alexandre
Assertions are used in standard java framework, but have hard side
effects : stopping the program immediately.
(cf
http://www.oracle.com/us/technologies/java/assertions-139853.html
"...The program will be aborted if the expression evaluates to false..")
With java it is possible, since the IDE and program are separated.
With Pharo you cannot, if you assert or throw an error in a sensible
place, you are likely to hang your image or to go for multiple errors
poping everywhere since you will break the state of an important object.
Another thing is that with dbc paradigm (assertions about your code),
there is no 'one invariant' but lots of, you will not be able to
express them in a single method, even if you could it would be hundreds
lines and you would have to copy them in all methods you will want to check.
The complete horror to maintain when you change your code.
The use of pragmas make it possible to activate or deactivate those
contracts at compilation time, there will no overhead in standard
execution without contracts.
Think of the pragmas as a way to "inject" invariant compiled code into
the compiled method for testing, then you recompile without for release.
Adding invariants will have *big* performance impact, probably several
orders of magnitude, I'll measure.
The overhead will of course come from calls of the checking framework,
but no doubt that with run-time reflexivity checking, you will have
something as sluggish too and you'll want to deactivate them at compile
time ...
I'm ready to bet on that
one beer
... :)
--
Alain
