On 26/02/2016 22:01, stepharo wrote:
You see this is a lot more difficult than it appears. ***Ideally*** old
should be a full copy of the object :)
But we can live with an approx solution.
You are right, I didn't thought about this problem at all,
I was thinking about the way to connect the two objects wrapping the
method calls with MetaLink, and the implications in the workflow of the
compiler front-end I did (rewrite several parts in fact).
I don't measure all the implications of making a deep copy, a shallow
copy or no copy (pointers only), but this could be a parameter at run-time
In any case I would really love to see if we can have contracts in
classes in Pharo libraries and
see how it improves them.
I would like to see the performance penalties.
What we could have is the following:
The extra cost is almost only in what is done in the checks :
I did the small test of using a FakeOrderedCollection (the one in
IceCompiler-Core-Tests package) and adding 10K integer to it, with and
without contracts and I had terrible results : more than 2mn with
contract checking, less than 1s without (I don't remember the exact
values) without, but no surprise at all, all the cost was in the
collection>>includes: check done in the postCondition:
postAdd: anObject
^ self includes: anObject
who does a scan of the collection ....
The cost of MetaLink or IceContractor and co is neglectable for a
run-time check IMHO, abd when releasing, all the code will be
recompiled without contract checking.
When we run the tests we run them twice
One with contracts on and one without contracts.
- first the results should be same :)
- second the contracts should be working
But this is done in the tests classes in the IceCompiler package with
very small runs and my intention is to add more tests.
I may be ashamed but you can look at the code... ( don't flame me please
, I'm no coder and I know I have to refactor lot of things) ... ;)
The approach I took is to have a blackbox to record test failures, no
assert, exceptions or whatever, I just record failures, because I wanted
to be non intrusive/agressive towards the system.
And this could be a parameter too.
I also recompiled the CriticBrowser with an invariant to see where
something was wrong with right-click/ban from selected package (DNU).
nb : the invariant was :
rulesModelChildrenUnderstandLeaves
<contract: invariant>
^ rulesModel selectedItem ifNil: [ true ] ifNotNil: [ :rule | rule
respondsTo: #leaves ]
because the DNU was on 'leaves' not understood.
:)
I was too short on TreeModel knowledge to go forward but this didn't
break CodeCritic.
Then we could start to have test harnessing (I know that guys from
argentina did some libraries for that)
and we could have better tests and find bugs in code by using the
contracts.
Stef
--
Alain
