Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54D37D41.2030706@hoa-project.net>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
 <54D37D41.2030706@hoa-project.net>
Date: Fri, 6 Feb 2015 01:09:42 +0900
Message-ID: <CAGa2bXa_E27ZK89j-C3c0-Kj8pDY4EN_8U6SQC2K19SNm46wqg@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=089e014953ec894153050e598aec
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e014953ec894153050e598aec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Ivan,

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 t=
ry
> 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 runtim=
e
> (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 =E2=80=9Cmetho=
d
> execution=E2=80=9D, we interpret or execute the invariants and the precon=
ditions
> expressed in the contract, the method runs and after =E2=80=9Cmethod exec=
ution=E2=80=9D, we
> interpret or execute the invariants and the postconditions expressed in t=
he
> 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.
If you think D like DbC support in language is wrong, could you list the
reason why it is?

Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e014953ec894153050e598aec--