On 06/02/15 09:44, Yasuo Ohgaki wrote:
Hi Ivan,
Hi Yasuo :-),
On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa
<ivan.ender...@hoa-project.net <mailto:ivan.ender...@hoa-project.net>>
wrote:
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.
I suppose so. Your research is to prove program correctness
mechanically, right?
It's tough theme.
Not to prove, to test. Proof kind be seen as an exhaustive testing process.
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!
Your request may be implemented. We may have any valid PHP code in
pre/post blocks and they works like hook.
Pre/post are only evaluated dev mode. There is zero performance
penalty in production system.
I've posted how it could be done. Please comment if you find any issues.
My main issue is that PHP is not appopriated to specify or describe
behaviors of different nature without being verbose. Using PHP here
would turn the code difficult to read and debug IMHO. When we use
contracts, it's rarely to express simple behaviors…
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 :-).
Do you think of any negative impact on PHP if we implement D like
in{}/out{} which allow any PHP syntax?
See my comments above :-).
