Invariants

[vmavra]

I'm wondering what was the need for adding invariants to the language. Now if I understand correctly, invariants are just class level test units but the disadvantages outweights the advantage of using them because this would most likely result in many assertations being made in places where they wouldn't be needed otherwise.

I can't really see myself a scenario where using them would be preferred over test units blocks. So could anyone come with some really useful example/examples?

Thanks!

[Charles]

Did you really mean to single out invariants? Or did you mean contracts in general, which would include "require" and "ensure", also known as pre-conditions and post-conditions? Like "contracts" vs. "unit tests".

[vmavra]

Did you really mean to single out invariants? Or did you mean contracts in general, which would include "require" and "ensure", also known as pre-conditions and post-conditions? Like "contracts" vs. "unit tests".

Indeed I was reffering only to invariants as they seem to me very similar to tests but with bigger disadvantages.

[Charles]

The organization really goes like this:

Cobra has contracts which include:
-- invariants
-- require / pre-condition
-- ensure / post-condition

These are boolean conditions that are checked at run-time during the execution of methods of objects.

Cobra has unit tests which include:
-- class level unit tests
-- method level unit tests (as well as properties, initializers, etc.)

Both contracts and unit tests are intended to improve software quality more rapidly than if they were not used. They have their pros and cons.

Contracts are more definition-oriented. When you can define your method in terms of boolean expressions, it can be very powerful. For one thing, the contracts execute the entire time your software is running which is extremely thorough. Also--and I'm having a hard time finding the words for this--there is an aspect of "completeness" when you can define your methods. You can forget a test case, but a definition is a definition.

Contracts also define the interface/behavior of the class.

However, unit tests can often be easier to write than contracts. And they show examples of using a method or object that are typically easier to learn from than contracts, particularly in more complex situations.

Because software quality continues to be a big issue, I am not a fan of adopting one technique and investing all my hopes in it. Cobra offers multiple features described in "Coding for Quality".

Regarding invariants, which was your question, here is a simple example (not tested or even compiled):

class Customer

    enum Status
        Good
        PastDue

    invariant
        .balance > 0 implies .status == Status.PastDue
        .balance <= 0 implies .status == Status.Good

    pro balance from var as decimal
        
    get status as Status
        if .balance > 0, return Status.PastDue
        else, return Status.Good

In that example, the invariant shows you what to expect regarding the properties of .balance and .status. Because it's expressed in code, it's for real (documentation can drift out of sync with the actual code and often does). Because it's based on succinct boolean expressions, it's fairly easy to read and understand. Because it's an invariant, it will be checked constantly at run-time and you will find out as early as possible if the software violates it. Early detection often reduces the amount of mental effort required to figure out where things first went wrong.

I tried to help by being extra thorough here. I hope it did.

[vmavra]

Ok, I think understand now, thanks. Last question, can invariants also be method level or are they class level only?

[Charles]

The method level analog to "invariant" is "require" and "ensure". Like "invariant" these are a list of boolean expressions that must evaluate as true. They serve as both quality control and a form of documentation as they are considered part of the public interface to the method.