Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81913
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEbg-4ZVaete6zzmTM0DtwRFn4g0PQET7ZDHdNtZuLtnyaCzNQ@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<7740874.yAST26hVNS@rofl>
	<CAEbg-4ZVaete6zzmTM0DtwRFn4g0PQET7ZDHdNtZuLtnyaCzNQ@mail.gmail.com>
Date: Thu, 5 Feb 2015 15:27:23 +0300
Message-ID: <CAEbg-4boM7=xgTuyUZcAxBmHQTv48NmSRk2LBnUvWJ1YmXyVww@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=f46d043890631424e3050e566dce
Subject: Re: [PHP-DEV] Design by Contract
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--f46d043890631424e3050e566dce
Content-Type: text/plain; charset=UTF-8

So, is it possible to use annotations for defining such metadata on
engine-level? This will be a good way to do this and to define custom
handlers via AST hooks, that can be able to patch method definition node
with concrete opcodes.

2015-02-05 15:24 GMT+03:00 Alexander Lisachenko <lisachenko.it@gmail.com>:

> 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
>>
>>
>

--f46d043890631424e3050e566dce--