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.
