Re: Design by Contract

On 05/02/15 17:09, Yasuo Ohgaki wrote:

Hi Ivan, Hi Yasuo :-),

On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa <ivan.enderlin@hoa-project.net <mailto:ivan.enderlin@hoa-project.net>> wrote:

    I just would like to point out some stuff.

    tl;dr: Contracts can be used to validate code (Design-by-Contract)
    or generate test data to validate code (Contract-based Testing).
    There are plenty of contract languages in the wild, each one
    addresses a specific problem (object, structured type, temporal
    logic, scenario etc.). If we try to develop a contract language,
    **IT WILL FAIL**, I guarantee it. The solution is to give tools to
    developers to ease the use of contracts, for example with Aspect
    Oriented Programming.

    There is a whole research PhD thesis about Contract-based Testing
    in PHP, which includes Design-by-Contract, automatic generation of
    complex test data and automatic generation of test suites:
    https://dl.dropboxusercontent.com/u/26317193/PhdThesis.pdf.
    Unfortunately, the thesis is in French but research articles are
    in English. You can found them here
    (http://hoa-project.net/En/Literature.html#Research):
      * Praspel: A Specification Language for Contract-Driven Testing
    in PHP (article:
    http://hoa-project.net/En/Literature/Research/Ictss11.pdf,
    keynote: http://keynote.hoa-project.net/Ictss11/EDGB11.pdf),
      * Grammar-Based Testing using Realistic Domains in PHP (article:
    http://hoa-project.net/En/Literature/Research/Amost12.pdf,
    keynote: http://keynote.hoa-project.net/Amost12/EDGB12.pdf),
      * A Constraint Solver for PHP Arrays (article:
    http://hoa-project.net/En/Literature/Research/Cstva13.pdf,
    keynote: http://keynote.hoa-project.net/Cstva13/EGB13.pdf).

    Concepts behind contracts are twofold:
      1. Design-by-Contract (DbC), validate code at compile time or at
    runtime (in the case of PHP, it will be at runtime),
      2. Contract-based Testing (CbT), generate test data based on
    contracts. Preconditions are used to generate inputs, and
    postconditions validate outputs. Invariants must hold before and
    after the execution of the SUT (System Under Test, here methods
    and functions).

    So there are two goals with contracts. We can only address
    validation (DbC) or both (DbC and CbT).

    From my own experience and study in this field (I am a PhD in the
    test domain), I suggest you to NOT introduce DbC and CbT in PHP.
    Why? Because the language used to express contracts (even if we
    use PHP) will be too much poor or too much inappropriate for test
    data validation or test data generation (resp. DbC or CbT).

    The articles listed above, in addition to the PhD thesis, present
    Praspel, a specification language for PHP, based on contracts.
    Praspel is used to validate and generate (test) data and test
    suites. This language is inspired from JML (Java Modeling
    Language) and ACSL (ANSI/C Specification Language) while
    addressing PHP features (weakly type for instance). But there is a
    lot more languages in the wild.
    Inventing another language will lead to a fail at a particular
    time, believe me. Each contract language has a specificity:
    Handling structured data, handling events, handling scenario (see
    Dwyer patterns for temporal linear logic) etc. We CANNOT address
    all these needs.

    However, there is a hope :-). DbC and CbT can be easily
    implemented with an Aspect Oriented Programming (AOP) paradigm.
    Before each “method execution”, we interpret or execute the
    invariants and the preconditions expressed in the contract, the
    method runs and after “method execution”, we interpret or execute
    the invariants and the postconditions expressed in the contract.
    No need to have a specific implementation in PHP's core for contracts.
    Moreover, we can enable or disable AOP in development or
    production environment, which ensures performances.

It sounds you are looking for way beyond what we discuss. If there are contracts, program correctness may be proven by contracts, but this kind of validation is not in scope. Proven? I don't dare to speak about proof here. If you would like to execute pre-, postconditions and invariants at runtime, you need a super language to define behaviors efficiently… and the problem is: What behaviors? Only the data type? The order of execution of methods? The time of execution of methods? A lot of constraints might be expressed in contracts.

There are a lot of researches in this field. PHP has a great opportunity to not close the doors by forcing a language. I suggest you to offer an API to hook on the runtime and “control” it, like AOP does. It will open the doors to so many interesting contributions!

If you think D like DbC support in language is wrong, could you list the reason why it is? I don't understand the question :-).

Cheers!