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.ender...@hoa-project.net <mailto:ivan.ender...@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!
