Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82026
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54D470FA.6000303@hoa-project.net>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
 <54D37D41.2030706@hoa-project.net> <CAGa2bXa_E27ZK89j-C3c0-Kj8pDY4EN_8U6SQC2K19SNm46wqg@mail.gmail.com>
 <54D470FA.6000303@hoa-project.net>
Date: Fri, 6 Feb 2015 17:44:30 +0900
Message-ID: <CAGa2bXaGE3QWjGxvRadLG0btA5wd1u5bZ=AAo6WQHE_Uek8iaw@mail.gmail.com>
To: "Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3041036a9db050e677004
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3041036a9db050e677004
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Ivan,

On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:

>
>
>
>  On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa <
> ivan.enderlin@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, fo=
r
>> 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 dat=
a
>> 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 i=
s
>> used to validate and generate (test) data and test suites. This language=
 is
>> inspired from JML (Java Modeling Language) and ACSL (ANSI/C Specificatio=
n
>> 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 structure=
d
>> data, handling events, handling scenario (see Dwyer patterns for tempora=
l
>> 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 =E2=80=9Cmeth=
od
>> execution=E2=80=9D, we interpret or execute the invariants and the preco=
nditions
>> expressed in the contract, the method runs and after =E2=80=9Cmethod exe=
cution=E2=80=9D, 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, b=
ut
> 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=E2=80=A6 and the problem is: Wha=
t
> behaviors? Only the data type? The order of execution of methods? The tim=
e
> 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 =E2=80=9Ccontrol=E2=80=9D it, like AOP does. It w=
ill 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
yohgaki@ohgaki.net

--001a11c3041036a9db050e677004--