Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81931
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: <54D37D41.2030706@hoa-project.net>
Date: Thu, 05 Feb 2015 15:25:05 +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: internals@lists.php.net
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
In-Reply-To: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040604020003030904070400"
Subject: Re: [PHP-DEV] Design by Contract
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

--------------040604020003030904070400
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Internal :-),

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.

Thoughts?


On 05/02/15 12:14, Dmitry Stogov wrote:
> Hi Yasuo,
>
> Following our conversation, I tried to imagine how DbC should look like in
> PHP from user perspective. Finally, I was influenced by the semantic
> proposed in D, and syntax proposed for Java. So, these are my initial
> thoughts:
>
> For php it may look like the following:
>
> function foo()
>      requre(<input-assert-expression>)
>      ensure(<output-assert-expression>)
> {
>    ...
> }
>
> It would require only one new reserved word "ensure".
>
> The assert expressions may be checked or not depending on ini directive.
> It should be also possible to prevent code generation for assertions (zero
> cost asserts). It was already implemented for
> https://wiki.php.net/rfc/expectations
>
> For inherited methods, only the self <input-assert-expression> should be
> checked, and all parent <output-asser-expression>. This is borrowed from D
> but not necessary to be repeated exactly.
>
> I think we shouldn't introduce "invariant" constraints for classes now. May
> be later.
>
> Implementation is going to generate code for input constraint after all
> RECV opcodes and before code for function body, and code for output
> constraint before RETURN opcode (may be reusing implementation of
> "finally").
>
> See:
> http://dlang.org/contracts.html
> http://jan.newmarch.name/java/contracts/paper-long.html
>
> Thanks. Dmitry.
>


--------------040604020003030904070400--