Hi Ivan, On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa < ivan.ender...@hoa-project.net> wrote:
> > > > On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa < > 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. 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. > 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? Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
