Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82020
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hoa-project.net designates 212.85.154.38 as permitted sender)
Message-ID: <54D470FA.6000303@hoa-project.net>
Date: Fri, 06 Feb 2015 08:44:58 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com> <54D37D41.2030706@hoa-project.net> <CAGa2bXa_E27ZK89j-C3c0-Kj8pDY4EN_8U6SQC2K19SNm46wqg@mail.gmail.com>
In-Reply-To: <CAGa2bXa_E27ZK89j-C3c0-Kj8pDY4EN_8U6SQC2K19SNm46wqg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090402070905000808010807"
Subject: Re: [PHP-DEV] Design by Contract
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

--------------090402070905000808010807
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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!

--------------090402070905000808010807--