On 28/01/2014 08:05, Yasuo Ohgaki wrote:
Hi all,
Hello :-),
I'm wandering if we could have DbC (Design by Contract) for PHP 6.
http://en.wikipedia.org/wiki/Design_by_contract
There is user land implementation already.
https://gitorious.org/higher-order-php/php-contracts/source/5b0a53b9732f0e4dbe79345212c84c74526def3b:
It could be done with dbc mode INI switch as follows.
When dbc=on, automatically includes
include __dbc_ . __SCRIPT_NAME__;
when a script is loaded. No error if there is not the script.
When function/method is called
__dbc_pre_. __FUNCTION__() is called before calling function().
__dbc_post_.___FUNCTION__() is called after function() call.
No error if there is not the function.
What kind of errord would you like to print? “The precondition has failed”, ok but why? With what data?
Class methods would be more complex, but basic idea is the same.
Issue would be what we should do with $this with class methods.
Automatic namespace might be nice to have for both function and class.
When dbc=off, these would be skipped at all.
It does not sacrifice performance at all for production while it could catch
various errors during development. It could do more complex assertion
than assert()
So the pre- and postconditions must be predicates, i.e. computing a boolean.
and it could check post condition that is difficult to achieve
by assert(). User could have their own strong type safety as long as they
have strict input validation. It could be used as complement of annotation.
Just an idea.
Any comments?
What about invariants which is the third part of DbC?
Did you heard about Praspel [1]. Praspel is a BISL (Behavioral Interface Specification Language), i.e. a specification language for contract-based testing I develop in my PhD thesis (in INRIA laboratories). You will find some materials here [2]. I recommend you to start by the presentations/keynotes. The idea is to allow the user to write contracts (precondition, postcondition, exceptional postcondition, invariant, behavior etc.), and we exploit them in order to generate (unit) tests automatically.
I'm reaching the end of my PhD and I'm currently writing the documentation and finalizing the tools. Today, we are able to:
(1) generate very different kinds of data (strings with regexs or grammars thanks to grammar-based testing algorithms [3, 4], arrays thanks to an array-solver [5] etc.)
(2) verify a contract with a Runtime Assertion Checker (please, see articles or directly the code [6])
(3) automatically generate (unit) tests that are executable with atoum's API [7, 8]
We are preparing videos and documentations in order to promote it up to June. I suggest to read the presentations, you will get an overview of all the work.
I think DbC must stay annotations, so in comments of the code. If contracts would be part of the PHP grammar, it would be disappointed for everyone because there is no unique way to express a contract: either with the language syntax itself (such as JML [9]) or with a dedicated language, such as Praspel. Both have pros and cons that I won't describe here (except if you ask).
However, having the Aspect Oriented Programming paradigm would be very appreciated. It would avoid a lot of instrumentations and static analyzes.
Regards.
[1] https://en.wikipedia.org/wiki/Praspel
[2] http://hoa-project.net/En/Literature.html#Research
[3] http://keynote.hoa-project.net/Amost12/EDGB12.pdf
[4] https://github.com/hoaproject/Compiler (documentation is under translation)
[5] http://keynote.hoa-project.net/Cstva13/EGB13.pdf
[6] https://github.com/hoaproject/Praspel/tree/master/AssertionChecker
[7] http://atoum.org/
[8] https://github.com/hoaproject/Hoathis-Atoum
[9] https://en.wikipedia.org/wiki/Java_Modeling_Language
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/