rfc:dbc2
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:dbc2 [2015/02/09 23:07] – yohgaki | rfc:dbc2 [2015/02/14 23:14] – fixed typo during review marcio | ||
---|---|---|---|
Line 2: | Line 2: | ||
* Version: 0.1 | * Version: 0.1 | ||
* Date: 2015-02-10 | * Date: 2015-02-10 | ||
- | * Author: Yasuo Ohgaki < | + | * Author: Yasuo Ohgaki < |
* Status: Draft | * Status: Draft | ||
* First Published at: http:// | * First Published at: http:// | ||
- | ===== Important Note==== | + | ===== Important Note ===== |
- | This RFC is a part of " | + | This RFC is an alternative approach to " |
http:// | http:// | ||
- | There are many way to achieve DbC. This RFC proposes DbC as function/ | + | Contracts can be defined without modification |
- | ===== Introduction ===== | + | Other advantages of a native implementation, |
- | Design by Contract (DbC) or Contract Programming is powerful program design concept based on **Contracts** that | + | |
+ | | ||
+ | | ||
+ | | ||
+ | * handling of contract inheritance | ||
- | - Define **precondition** contract for methods/ | + | All of the above applies to PHP. |
- | - Define **postcondition** contract for methods/ | + | |
- | - Define **invariant** contract for methods/ | + | |
- | These contracts are evaluated development time only. Therefore, there is **no performance penalty** with DbC. | + | ===== Introduction ===== |
- | * http:// | + | The D manual contains the following succinct definition of contracts: |
- | * http:// | + | |
- | ====DbC Changes | + | > The idea of a contract is simple - it's just an expression that must evaluate to true. If it does not, the contract |
- | ==CalleR and CalleE responsibility and validation: | + | This should be easily comprehensible, it further validates |
- | * With modularized design without DbC, the more code is consolidated, | + | |
- | * With DbC, parameter checks are done as **precondition**. Passing valid parameter to a function is __calleR__ responsibility. | + | |
- | ==Exit value validation:== | + | ===== Proposal ===== |
- | * Without native DbC, return value validity cannot be checked without scattered assert() for every place function is used. \\ i.e. Programmers has to write " | + | |
- | * With native DbC, return value validity is checked as **postcondition**. It does not require scattered assert(). | + | |
- | ==Class state validation:== | + | Support for the following contracts will be introduced: |
- | * With native DbC, **invariant** condition may be defined. **Invariant** allows programmers consolidate class state which must be TRUE for always. \\ e.g. $account_balance >= 0 | + | |
- | **precondition** | + | * precondition |
+ | * postcondition | ||
+ | * invariant | ||
- | DbC reverses the responsibility caller | + | ===== Pre and Post Condition ===== |
- | With proper use of DbC concept, it is known **programs to be more robust, secure and faster**. Languages designed lately have native DbC support. e.g. D language. Almost all languages have some kind of DbC supports today. | + | These contracts should |
- | ====Readability of Code / Testing Code==== | + | Multiple precondition and postcondition contracts may be used. The expressions are just a regular PHP expressions. They are evaluated in the function scope, and can access arguments and other scope variables, and return value (via a reserved name). Pre and post-conditions can't be defined for abstract methods and methods defined in interfaces. |
- | Since contracts are written in function/method definition, it's much easier to find function/method spec compared to conditions written in UnitTests. It also enables contract check for running applications operated by humans. | + | < |
+ | function | ||
+ | require($a > 0) | ||
+ | require($b > 0) | ||
+ | return($ret, | ||
+ | { | ||
+ | return $a + $b; | ||
+ | } | ||
+ | </code> | ||
- | DbC is __NOT__ a complement of UnitTest, but it provide additional way of testing programs. Programs should | + | this code is going to be evaluated as |
+ | < | ||
+ | function add(int $a, int $b) : int | ||
+ | { | ||
+ | assert($a > 0); | ||
+ | assert($b > 0); | ||
+ | $ret = $a + $b; | ||
+ | assert($ret > 0, " | ||
+ | return $ret; | ||
+ | } | ||
+ | </ | ||
- | ====General Concern of Design by Contract==== | + | ===== Invariant ===== |
- | Some may concern that lack of checks under production environment. However, all inputs to programs should validate input parameter validity right after input parameters are passed to program. | + | Invariant contracts are declared using **require** inside class body. Multiple invariant contracts |
- | This is basic principle of secure programs. Users should not DbC everywhere. User should have proper defense in depth as security measure. Security standard like "ISO 27000" or security guideline like " | + | < |
+ | class Accumulator { | ||
+ | private $sum = 0; | ||
+ | |||
+ | function add(int $a) | ||
+ | require($a > 0) | ||
+ | { | ||
+ | $this-> | ||
+ | } | ||
+ | require($this-> | ||
+ | } | ||
+ | </ | ||
- | ===== Proposal ===== | + | this code is going to be evaluated as |
- | Introduce native contracts " | + | < |
+ | class Accumulator { | ||
+ | private $sum = 0; | ||
+ | |||
+ | function add(int $a) | ||
+ | { | ||
+ | assert($a > 0); | ||
+ | assert($this-> | ||
+ | $this->sum += $a; | ||
+ | assert($this-> | ||
+ | } | ||
+ | } | ||
+ | </code> | ||
- | While new usage of require, return may seem strange at first, users can use familiar PHP syntax for DbC definitions. | + | **Invariant contracts are not evaluated when object properties are changed from outside the class scope.** |
- | * require(assert-expr [,' | + | ====Contracts Inheritance Rules==== |
- | * return(assert-expr [,' | + | |
- | * < | + | |
- | **require**, **return** behave just like assert(). | + | Contracts are constant, this has the following implications: |
+ | * a derived class must satisfy invariant contracts of it's parent | ||
+ | * a derived class overriding a method must satisfy the pre and post condition contracts of it's prototype. | ||
- | ====Example without **invariant**==== | + | Thus, given the following |
- | <code php> | + | |
- | class Product { | + | |
- | protected $inventory; | + | |
- | // User is supposed to check inventory first | + | < |
- | | + | class Child { |
- | require($quantity | + | require ($this->age < 18); |
- | { | + | |
- | | + | |
- | } | + | require(somethingAbout($input)) { |
+ | /* ... */ | ||
+ | | ||
- | | + | |
- | function sell($quantity) | + | |
- | require($quantity > 0) | + | |
- | return($ret >= 0) // We have to think of how to specify $ret. Use block? return($ret) {assert($ret >= 0);} as Dmitry suggested. | + | |
- | { | + | |
- | return $this> | + | |
- | } | + | |
} | } | ||
- | </ | ||
- | ====Example with **invariant**==== | + | class Monster extends Child { |
- | <code php> | + | |
- | class Product | + | |
- | | + | |
- | // Invariants must be TRUE for this class always | + | public |
- | | + | |
- | | + | /* ... */ |
- | } | + | |
- | | + | |
- | function haveEnoughInventory($quantity) | + | |
- | require($quantity > 0) | + | |
- | { | + | |
- | return (bool) ($this-> | + | |
- | } | + | |
- | + | ||
- | // Sell inventory | + | |
- | function sell($quantity) | + | |
- | require($quantity > 0) | + | |
- | { | + | |
- | return $this> | + | |
- | } | + | |
} | } | ||
</ | </ | ||
+ | |||
+ | //Monster// must not break **any** contract in //Child//. | ||
====Execution Control==== | ====Execution Control==== | ||
- | Introduce | + | A new " |
- | A method/ | + | * dbc=on |
+ | * dbc=off | ||
+ | * dbc=zero_cost - don't generate code for contracts. This may be set only in php.ini and can't be changed through ini_set(). | ||
- | ===Development mode: dbc=On === | + | The default value is " |
- | - require() conditions | + | ===Contracts Execution Order=== |
- | - __invariant() | + | |
- | - method() | + | |
- | - __invariant() | + | |
- | - return() conditions | + | |
- | ===Production mode: dbc=Off === | + | If "dbc" is set to " |
- | - method() | + | |
- | + | - all require() contracts (invariant) for this class and parents | |
+ | | ||
+ | - all require() contracts (invariant) for this class and parents | ||
+ | - all return() contracts (postcondition) defined for this function (and prototype where applicable) | ||
+ | |||
+ | **Invariant and Special Methods** | ||
+ | |||
+ | * < | ||
+ | * < | ||
+ | |||
+ | **Static Call** | ||
+ | |||
+ | * Only pre and post conditions are executed. | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 144: | Line 173: | ||
* No additional keyword | * No additional keyword | ||
- | * __invariant() is a reserved method name | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
Line 158: | Line 186: | ||
==== To Opcache ==== | ==== To Opcache ==== | ||
- | + | Opcache will have to be extended to support contracts and store them in shared memory. | |
- | Dmitry, could you write impact when discussion is finished? | + | |
==== New Constants ==== | ==== New Constants ==== | ||
Line 166: | Line 192: | ||
==== php.ini Defaults ==== | ==== php.ini Defaults ==== | ||
- | + | dbc=Off for all (INI_ALL) | |
- | dbc=Off for all | + | |
* hardcoded default values | * hardcoded default values | ||
Line 174: | Line 199: | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
+ | * Contracts inheritance rules | ||
+ | * Consider introduction of **static require()** as class invariant for static methods | ||
* Need to discuss syntax | * Need to discuss syntax | ||
* How to manage votes for 2 RFCs | * How to manage votes for 2 RFCs | ||
- | |||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== |
rfc/dbc2.txt · Last modified: 2018/03/01 23:19 by carusogabriel