Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81911
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7740874.yAST26hVNS@rofl>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<7740874.yAST26hVNS@rofl>
Date: Thu, 5 Feb 2015 15:24:38 +0300
Message-ID: <CAEbg-4ZVaete6zzmTM0DtwRFn4g0PQET7ZDHdNtZuLtnyaCzNQ@mail.gmail.com>
To: Patrick Schaaf <php@bof.de>
Cc: PHP internals list <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>, 
	Yasuo Ohgaki <yohgaki@ohgaki.net>
Content-Type: multipart/alternative; boundary=bcaec53d55073ccade050e566352
Subject: Re: [PHP-DEV] Design by Contract
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--bcaec53d55073ccade050e566352
Content-Type: text/plain; charset=UTF-8

Hello, internals!

From my point of view, contracts should not affect execution of source code
in production env, or can be enabled partially. I have implemented DbC
paradigm on top of the AOP layer, so each contract can be defined via
annotation and looks pretty nice, for example :

use PhpDeal\Annotation as Contract;

/**
 * Simple trade account class
 * @Contract\Invariant("$this->balance > 0")
 */
class Account implements AccountContract
{

    /**
     * Current balance
     *
     * @var float
     */
    protected $balance = 0.0;

    /**
     * Deposits fixed amount of money to the account
     *
     * @param float $amount
     *
     * @Contract\Verify("$amount>0 && is_numeric($amount)")
     * @Contract\Ensure("$this->balance == $__old->balance+$amount")
     */
    public function deposit($amount)
    {
        $this->balance += $amount;
    }

    /**
     * Returns current balance
     *
     * @Contract\Ensure("$__result == $this->balance")
     * @return float
     */
    public function getBalance()
    {
        return $this->balance;
    }
}

All contracts (verify|ensure) are enforced only when DbC is enabled and
doesn't have an impact on execution for production mode. Moreover, all
annotations are parsed only once, decorators are generated too, so overhead
is minimal even for debug mode. Engine takes care to insert appropriate
before/around checks via an aspect
https://github.com/lisachenko/php-deal/blob/master/src/PhpDeal/Aspect/ContractCheckerAspect.php

Here is a simple snippet of pointcut definition and advice body:

    /**
     * Verifies pre-condition contract for the method
     *
     * @param MethodInvocation $invocation
     * @Before("@annotation(PhpDeal\Annotation\Verify)")
     *
     * @throws ContractViolation
     */
    public function preConditionContract(MethodInvocation $invocation)
    {
        $object = $invocation->getThis();
        $args   = $this->getMethodArguments($invocation);
        $scope  = $invocation->getMethod()->getDeclaringClass()->name;

        foreach ($invocation->getMethod()->getAnnotations() as $annotation) {
            if (!$annotation instanceof Contract\Verify) {
                continue;
            }

            if (!$this->isContractSatisfied($object, $scope, $args,
$annotation)) {
                throw new ContractViolation($invocation, $annotation->value);
            };
        }
    }





2015-02-05 15:13 GMT+03:00 Patrick Schaaf <php@bof.de>:

> On Thursday 05 February 2015 15:14:04 Dmitry Stogov wrote:
> >
> > function foo()
> >     requre(<input-assert-expression>)
> >     ensure(<output-assert-expression>)
> > {
> >   ...
> > }
> >
> > It would require only one new reserved word "ensure".
>
> Regarding syntax.... This could be another place where the irrationally-
> dreaded declare would make sense:
>
> function foo() {
>     declare(pre) {
>       if (whatever...) return false;
>       // arbitrary PHP code
>     }
>     declare(post=$resultvar) {
>       if ($resultvar == XXX) return true;
>       return false;
>     }
> }
>
> This way, no new reserved words are needed at all, and the programmer can
> give
> a name to the "variable that holds the result" locally to avoid clashes
> with
> anything else in the function.
>
> I'm a bit undecided whether returning true/false there to give the verdict,
> would be the best way. Maybe better would be another use for declare,
> without
> a block, to declare that the pre/postcondition failed - giving a nice
> place to
> put a suitable message, too. And again without introducing any extra
> keywords:
>
> function foo() {
>     declare(post=$resultvar) {
>         if ($resultvar == XXX) declare(fail="My $resultvar looks fishy");
>     }
> }
>
> best regards
>   Patrick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--bcaec53d55073ccade050e566352--