rfc:dbc
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
rfc:dbc [2015/02/04 11:41] – created yohgaki | rfc:dbc [2018/03/01 23:19] (current) – Typo "Under Discussion" carusogabriel | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Native | + | ====== PHP RFC: Implementing |
- | * Version: 0.1 | + | * Version: 0.4 |
- | * Date: 2015-02-05 | + | * Date: 2015-02-09 |
- | * Author: | + | * Author: |
- | * Status: | + | * Status: Under Discussion |
* First Published at: http:// | * First Published at: http:// | ||
- | This is a suggested template for PHP Request | + | |
- | Read https:// | + | type hinting. The reason is that the design and syntax |
+ | decisions that will be made about scalar type hinting heavily impact the | ||
+ | contents of this RFC. Proposal is subject | ||
+ | | ||
+ | ===== Preamble ===== | ||
- | Quoting [[http:// | + | This RFC is part of " |
- | > PHP is and should remain: | + | * https:// |
- | > 1) a pragmatic web-focused language | + | |
- | > 2) a loosely typed language | + | |
- | > 3) a language which caters to the skill-levels and platforms of a wide range of users | + | |
- | Your RFC should move PHP forward following his vision. As [[http://news.php.net/php.internals/66065|said by Zeev Suraski]] " | + | There is alternative implementation proposal by " |
- | large chunk of our userbase, and not something that could be useful in some | + | |
- | extremely specialized edge cases [...] Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with | + | * https:// |
- | every new feature, and the scope of the goodness that those new features bring." | + | |
+ | |||
+ | The original idea of introducing DbC in PHP comes from Yasuo Ohgaki | ||
+ | < | ||
+ | |||
+ | Then, I offered to write an RFC where I propose to include DbC constraints in | ||
+ | doc comments. This is the present document. | ||
+ | |||
+ | While we agree on the concept, Yasuo is preferring a D-like syntax, which he's proposing in [[https://wiki.php.net/rfc/dbc2|another RFC]]. | ||
+ | IMO, adopting the D syntax would be fine if we designed | ||
+ | best way to include | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | The elevator pitch for the RFC. The first paragraph | + | |
+ | For more than 10 years (since PHP 5 was released), | ||
+ | seen a lot of discussions about strict vs loose typing, type hinting and | ||
+ | related features. Through these discussions, | ||
+ | them as early as possible. Strictifying types is an approach but, unfortunately, | ||
+ | so well with PHP as a loose-typed language. | ||
+ | |||
+ | This RFC proposes an alternative approach, already present in several | ||
+ | languages, named ' | ||
+ | |||
+ | Here is the definition of a contract, according to the D language documentation : | ||
+ | |||
+ | | ||
+ | to true. If it does not, the contract is broken, and by definition, the program | ||
+ | has a bug in it. Contracts form part of the specification for a program, moving | ||
+ | it from the documentation to the code itself. And as every programmer knows, | ||
+ | documentation tends to be incomplete, out of date, wrong, or non-existent. | ||
+ | Moving the contracts into the code makes them verifiable against the program. | ||
+ | |||
+ | For more info on the DbC theory, use the links in the ' | ||
+ | |||
+ | An important point in DbC theory is that contracts are checked during the development/ | ||
+ | A global switch allows to turn DbC checks off when the software goes to production. | ||
+ | |||
+ | So, what we need to retain : | ||
+ | |||
+ | * DbC constraints can be highly sophisticated as we don't care about performance. | ||
+ | * As they are checked at runtime, DbC constraints can check types AND values. | ||
+ | * DbC checks must not handle checks that must always run, even in production. Validating user input, for instance, must remain out of DbC constraints. | ||
+ | * DbC and 'Test Driven Development' | ||
+ | |||
+ | ===== Examples ===== | ||
+ | |||
+ | First, an example of a function defining input and output constraints | ||
+ | (' | ||
+ | |||
+ | <code php> | ||
+ | // | ||
+ | /** | ||
+ | * Compute area of a triangle | ||
+ | * | ||
+ | * This function computes the area of a triangle using Heron' | ||
+ | * | ||
+ | * @param number $a Length of 1st side | ||
+ | * @requires ($a >= 0) | ||
+ | * @param number $b Length of 2nd side | ||
+ | * @requires ($b >= 0) | ||
+ | * @param number $c Length of 3rd side | ||
+ | * @requires ($c >= 0) | ||
+ | * @requires ($a <= ($b+$c)) | ||
+ | * @requires ($b <= ($a+$c)) | ||
+ | * @requires ($c <= ($a+$b)) | ||
+ | * | ||
+ | * @return number The triangle area | ||
+ | * @ensures ($> >= 0) | ||
+ | */ | ||
+ | |||
+ | function triangleArea($a, | ||
+ | { | ||
+ | $halfPerimeter = ($a + $b + $c) / 2; | ||
+ | |||
+ | return sqrt($halfPerimeter | ||
+ | * ($halfPerimeter - $a) | ||
+ | * ($halfPerimeter - $b) | ||
+ | * ($halfPerimeter - $c)); | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Then : | ||
+ | |||
+ | <code php> | ||
+ | $area=triangleArea(4, | ||
+ | -> OK | ||
+ | |||
+ | $area=triangleArea(' | ||
+ | -> PHP Fatal error: triangleArea: | ||
+ | |||
+ | $area=triangleArea(10, | ||
+ | -> PHP Fatal error: triangleArea: | ||
+ | </ | ||
+ | |||
+ | Another example with a PHP clone of str_replace() : | ||
+ | |||
+ | <code php> | ||
+ | // | ||
+ | /** | ||
+ | * Replace all occurrences of the search string with the replacement string | ||
+ | * | ||
+ | * This function returns a string or an array with all occurrences of search | ||
+ | * in subject replaced with the given replace value. | ||
+ | * | ||
+ | * @param string|array(string) $search The value being searched for (aka needle) | ||
+ | * @param string|array(string) $replace The replacement value that replaces found search values | ||
+ | * @param string|array(string) $subject The string or array being searched and replaced on | ||
+ | * @param.out int $count The number of replacements performed | ||
+ | * @ensures ($count >= 0) | ||
+ | * @return string|array(string) A string or an array with the replaced values | ||
+ | * | ||
+ | * Ensure that returned value is the same type as input subject : | ||
+ | * @ensures (is_array($> | ||
+ | */ | ||
+ | |||
+ | function str_replace($search, | ||
+ | { | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | Note that we didn't provide any constraint on $count input, as this | ||
+ | parameter is used for output only. | ||
+ | |||
+ | Finally, we rewrite the first example as a class : | ||
+ | |||
+ | <code php> | ||
+ | <?php | ||
+ | /** | ||
+ | * @invariant ($this-> | ||
+ | * @invariant ($this-> | ||
+ | * @invariant ($this-> | ||
+ | */ | ||
+ | |||
+ | class triangle | ||
+ | { | ||
+ | /*-- Properties */ | ||
+ | |||
+ | /** @var number Side lengths */ | ||
+ | |||
+ | private $a,$b,$c; | ||
+ | |||
+ | // | ||
+ | /** | ||
+ | * @param number $a Length of 1st side | ||
+ | * @param number $b Length of 2nd side | ||
+ | * @param number $c Length of 3rd side | ||
+ | * | ||
+ | * No need to repeat constraints on values as they are checked by class invariants. | ||
+ | */ | ||
+ | |||
+ | public function __construct($a, | ||
+ | { | ||
+ | $this-> | ||
+ | $this-> | ||
+ | $this-> | ||
+ | } | ||
+ | |||
+ | // | ||
+ | /** | ||
+ | * Compute area of a triangle | ||
+ | * | ||
+ | * This function computes the area of a triangle using Heron' | ||
+ | * | ||
+ | * @return number The triangle area | ||
+ | * @ensures ($> >= 0) | ||
+ | */ | ||
+ | |||
+ | public function area() | ||
+ | { | ||
+ | $halfPerimeter = ($this-> | ||
+ | |||
+ | return sqrt($halfPerimeter | ||
+ | * ($halfPerimeter - $this-> | ||
+ | * ($halfPerimeter - $this-> | ||
+ | * ($halfPerimeter - $this-> | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | and check DbC constraints : | ||
+ | |||
+ | <code php> | ||
+ | $t= new triangle(4, | ||
+ | -> OK | ||
+ | |||
+ | $t=new triangle(' | ||
+ | -> PHP Fatal error: triangle:: | ||
+ | |||
+ | $area=triangleArea(10, | ||
+ | -> PHP Fatal error: triangle: DbC invariant violation (($this-> | ||
+ | </ | ||
===== Proposal ===== | ===== Proposal ===== | ||
- | All the features and examples of the proposal. | ||
- | To [[http:// | + | DbC defines three constraint types : |
- | for inclusion in one of the world' | + | |
- | Remember | + | * pre-conditions: |
+ | * post-conditions: | ||
+ | * class invariants: Constraints on class properties. | ||
+ | |||
+ | In this document, we propose a mechanism to implement these constraints in the PHP world. | ||
+ | |||
+ | ==== Syntax ==== | ||
+ | |||
+ | We propose to include the DbC directives in phpdoc blocks. Here are the | ||
+ | main reasons, that make it, in my opinion, a better choice than every other syntaxes | ||
+ | proposed so far : | ||
+ | |||
+ | * it allows to keep the source code executable on previous PHP interpreters. | ||
+ | * Phpdoc comments, while not perfect, have always played the role of annotations in PHP. ' | ||
+ | * DbC can use a great part of the already-written phpdoc informations (@param and @return types, @throws information too). So, unchanged code could already benefit of DbC. | ||
+ | |||
+ | Note: Some people on the mailing list are religiously opposed to including information | ||
+ | in phpdoc blocks, despite the fact that thousands of people already use them | ||
+ | for this purpose. The reason is that the parser cannot handle that. I agree, but | ||
+ | that's not a task for the parser, that's a task for an external tool. We just need | ||
+ | the hooks. | ||
+ | |||
+ | ==== Side effects ==== | ||
+ | |||
+ | As DbC, by nature, can be turned on and off, DbC checks must not modify | ||
+ | anything in the environment. | ||
+ | |||
+ | While enforcing this is partially possible in theory, this implementation will leave it to | ||
+ | the developer' | ||
+ | |||
+ | ==== DbC types ==== | ||
+ | |||
+ | DbC types are an extension and formalization of the pre-existing phpdoc | ||
+ | argument/ | ||
+ | |||
+ | DbC types are not present in original DbC syntax (like Eiffel or D implementation), | ||
+ | This is a PHP-specific addition to enhance simplicity and readability. DbC types can be | ||
+ | seen as built-in conditions. | ||
+ | |||
+ | Here are the main benefits of defining a set of DbC types : | ||
+ | |||
+ | * PHP is_xxx() functions are not as intuitive as they may seem, as they are based on zval types (an equivalent of strict type checks). They are not appropriate for people who just want to accept a limited set of type juggling (accepting a numeric string from a DB, for instance). Unfortunately, | ||
+ | * As it was already said, tons of source code already contains argument return/ | ||
+ | * Readability is a key point too: just compare a type like ' | ||
+ | * DbC types allow static analysis, which is practically impossible with conditions. | ||
+ | * A lot of other analyzis/ | ||
+ | |||
+ | DbC types are used to check : | ||
+ | |||
+ | * arguments sent to a function | ||
+ | * arguments passed by ref returned by a function | ||
+ | * the function' | ||
+ | * the type of class properties | ||
+ | |||
+ | === Syntax === | ||
+ | |||
+ | DbC types don't contain whitespaces. | ||
+ | |||
+ | Here is a pseudo-grammar of DbC types : | ||
+ | |||
+ | < | ||
+ | dbc-type = compound-type | ||
+ | |||
+ | compound-type = type, { " | ||
+ | |||
+ | type = " | ||
+ | | " | ||
+ | | " | ||
+ | | " | ||
+ | | " | ||
+ | | " | ||
+ | | array-type | ||
+ | | " | ||
+ | | object-type | ||
+ | | resource-type | ||
+ | | " | ||
+ | | " | ||
+ | | " | ||
+ | | " | ||
+ | | " | ||
+ | |||
+ | array-type = " | ||
+ | | " | ||
+ | |||
+ | object-type = " | ||
+ | | " | ||
+ | |||
+ | resource-type = " | ||
+ | | " | ||
+ | </ | ||
+ | |||
+ | === DbC types vs zval types === | ||
+ | |||
+ | DbC types follow specific rules to match PHP zvals. These rules are less permissive than | ||
+ | PHP API type juggling and previously-proposed scalar ' | ||
+ | these types try to be a more intuitive compromise between both. | ||
+ | |||
+ | Strict typing is sometimes required. That's why DbC types also include a set of | ||
+ | strict types. | ||
+ | |||
+ | Note that the benefit of DbC, here, is that we can match depending on zval values, as | ||
+ | we don't care about performance. | ||
+ | |||
+ | ^ ^ Zval type ^^^^^^^^ | ||
+ | ^ DbC type ^ IS_NULL ^ IS_LONG ^ IS_DOUBLE ^ IS_BOOL(1) ^ IS_ARRAY ^ IS_OBJECT ^ IS_STRING ^ IS_RESOURCE ^ | ||
+ | ^ integer | ||
+ | ^ integer! | ||
+ | ^ number | ||
+ | ^ float! | ||
+ | ^ string | ||
+ | ^ string! | ||
+ | ^ array | No | ||
+ | ^ callable | ||
+ | ^ object | ||
+ | ^ resource | ||
+ | ^ scalar | ||
+ | ^ null | ||
+ | ^ mixed | Yes | Yes | Yes | Yes | ||
+ | ^ boolean | ||
+ | ^ boolean! | ||
+ | |||
+ | * (1) IS_TRUE/ | ||
+ | * (2) only if decimal part is null\\ | ||
+ | * (3) only if is_numeric(string) returns true and decimal part is null\\ | ||
+ | * (4) only if is_numeric(string) returns true\\ | ||
+ | * (5) only if is_callable(arg, | ||
+ | * (6) only if class defines a %%__%%toString() method\\ | ||
+ | * (7) O is false, 1 is true. Other values don't match (to be discussed) | ||
+ | |||
+ | === DbC types === | ||
+ | |||
+ | == integer == | ||
+ | |||
+ | An integer value, positive or negative. | ||
+ | |||
+ | Note: This type is NOT equivalent to is_int($arg), | ||
+ | accepts the IS_LONG zval type. | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | == integer! == | ||
+ | |||
+ | A zval-type-based integer value, positive or negative. | ||
+ | |||
+ | Note: This type is equivalent to is_int($arg). | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | == number == | ||
+ | |||
+ | Any value that returns true through is_numeric(). | ||
+ | |||
+ | Equivalent to ' | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | == float! == | ||
+ | |||
+ | A zval-type-based float value. | ||
+ | |||
+ | Note: This type is equivalent to is_float($arg). | ||
+ | |||
+ | == string == | ||
+ | |||
+ | An entity that can be represented by a string. Numeric values are accepted as strings, | ||
+ | as well as objects whose class defines a __toString() method. | ||
+ | |||
+ | == string! == | ||
+ | |||
+ | Accepts IS_STRING zvals and objects whose class defines a __toString() method. | ||
+ | |||
+ | == array == | ||
+ | |||
+ | A PHP array. | ||
+ | |||
+ | Complements: | ||
+ | This defines the acceptable types of the array values. This definition can be nested. | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | < | ||
+ | * @param array $arr ... | ||
+ | * @param string|array(string) $... # Matches a string or an array of strings | ||
+ | * @param array(array(string|integer)) $... # A 2-dimension array containing strings and int only | ||
+ | </ | ||
+ | |||
+ | == callable == | ||
+ | |||
+ | A string, object or array returning true through ' | ||
+ | |||
+ | Please consult the [[http:// | ||
+ | |||
+ | == object == | ||
+ | |||
+ | An instance object. | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | Complements: | ||
+ | the object is of this class or has this class as one of its parents (equivalent to is_a()). | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | < | ||
+ | * @param object $arg | ||
+ | * @param object(Exception) $e | ||
+ | * @param object(MongoClient)|null $conn | ||
+ | </ | ||
+ | |||
+ | == resource == | ||
+ | |||
+ | A PHP resource. | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | Complements: | ||
+ | string provided when defining a resource via zend_register_list_destructors_ex(). As | ||
+ | we don't support whitespaces in argument types, whitespaces present in the original resource | ||
+ | type must be replaced with an underscore character (' | ||
+ | |||
+ | The easiest way to display the string corresponding to a resource type is to display | ||
+ | an existing resource using var_dump(). | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | < | ||
+ | * @param resource(OpenSSL_key) $... | ||
+ | * @param resource(pgsl_link) $... | ||
+ | </ | ||
+ | |||
+ | == scalar == | ||
+ | |||
+ | Shortcut for ' | ||
+ | |||
+ | Equivalent to ' | ||
+ | |||
+ | == null == | ||
+ | |||
+ | This corresponds exactly to the IS_NULL zval type. | ||
+ | |||
+ | Equivalent to ' | ||
+ | |||
+ | Note that a number with a 0 value does not match ' | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | < | ||
+ | * @param string|null $... | ||
+ | * @param resource(pgsl_link) $... | ||
+ | * @return null | ||
+ | </ | ||
+ | |||
+ | == mixed == | ||
+ | |||
+ | Accepts any zval type & value (catch-all). | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | == boolean == | ||
+ | |||
+ | A boolean value (true or false). | ||
+ | |||
+ | In PHP 7, IS_BOOL is replaced with IS_TRUE and IS_FALSE. | ||
+ | |||
+ | Equivalent to ' | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | == boolean! == | ||
+ | |||
+ | Accepts IS_BOOL zvals only (IS_TRUE/ | ||
+ | |||
+ | Synonyms: ' | ||
+ | |||
+ | ==== Pre-conditions ==== | ||
+ | |||
+ | These conditions are checked at the beginning of a function or method, after | ||
+ | arguments have been received, but before starting executing the function body. | ||
+ | |||
+ | Pre-conditions are expressed in two forms : argument types, and explicit assertions. | ||
+ | Argument types are used first and explicit assertions supplement argument types | ||
+ | with additional conditions (like conditions between arguments). | ||
+ | |||
+ | Argument types are checked before explicit assertions, meaning that | ||
+ | explicit assertions can assume correct types. | ||
+ | |||
+ | === Optional arguments === | ||
+ | |||
+ | When an optional argument is not set by the caller, its input (and possibly output) types are not | ||
+ | checked. This allows to set a default value which does not match the argument' | ||
+ | declared input type. | ||
+ | |||
+ | Example : | ||
+ | |||
+ | <code php> | ||
+ | /** | ||
+ | * ... | ||
+ | * @param int $flag ... | ||
+ | * ... | ||
+ | */ | ||
+ | |||
+ | function myFunc(..., $flag=null) | ||
+ | { | ||
+ | if (is_null($flag)) { | ||
+ | // Here, we are sure that the parameter was not set by the caller, as | ||
+ | // a null value sent by the caller would be refused by DbC input check. | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | === Input assertions === | ||
+ | |||
+ | These conditions supplement argument types for more complex conditions. They | ||
+ | are executed in the function scope before executing the function' | ||
+ | |||
+ | Syntax : | ||
+ | |||
+ | < | ||
+ | /** | ||
+ | * ... | ||
+ | * @requires < | ||
+ | * ... | ||
+ | </ | ||
+ | |||
+ | where < | ||
+ | |||
+ | These assertions can appear anywhere in the phpdoc block. They are executed in | ||
+ | the same order as they appear in the doc block. | ||
+ | |||
+ | === Inheritance === | ||
+ | |||
+ | The DbC theory, in accordance with the [[http:// | ||
+ | states that a subclass can override pre-conditions only if it loosens them. | ||
+ | |||
+ | The logic we implement is in the spirit of the way PHP handles class constructors/ | ||
+ | |||
+ | * Function pre-conditions are checked. If the function does not define any pre-condition, | ||
+ | * A special pre-condition is introduced. The ' | ||
+ | * The special ' | ||
+ | |||
+ | ==== Post-conditions ==== | ||
+ | |||
+ | Post-conditions are checked at function' | ||
+ | executed in the function scope. | ||
+ | |||
+ | They are generally used to check the returned type and value, and arguments | ||
+ | returned by ref. | ||
+ | |||
+ | When a function exits because an exception was thrown, | ||
+ | the function' | ||
+ | checked. | ||
+ | |||
+ | === Returned type === | ||
+ | |||
+ | Syntax: | ||
+ | |||
+ | < | ||
+ | * @return < | ||
+ | </ | ||
+ | |||
+ | The syntax of < | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | < | ||
+ | * @return resource|null | ||
+ | |||
+ | // For a factory: | ||
+ | |||
+ | * @return object(MyClass) | ||
+ | </ | ||
+ | |||
+ | === Argument return type === | ||
+ | |||
+ | This is the return type & value of the arguments passed by reference. | ||
+ | |||
+ | Syntax: | ||
+ | |||
+ | < | ||
+ | * @param.out < | ||
+ | </ | ||
+ | |||
+ | Note that an argument passed by reference can have a ' | ||
+ | its input type and/or a ' | ||
+ | In the str_replace() example above, we don't define an input type for $count | ||
+ | because it is undefined. | ||
+ | |||
+ | === Output assertions === | ||
+ | |||
+ | Syntax: | ||
+ | |||
+ | < | ||
+ | * @ensures < | ||
+ | </ | ||
+ | |||
+ | As with input assertions, < | ||
+ | in the function scope. The only addition is that the ' | ||
+ | replaced with the function' | ||
+ | |||
+ | As with pre-conditions, | ||
+ | |||
+ | === Inheritance === | ||
+ | |||
+ | The inheritance rules are the same as the ones for pre-conditions. | ||
+ | |||
+ | Unlike the Eiffel or D implementations, | ||
+ | only if the child requires it using a ' | ||
+ | |||
+ | ==== Class constraints ==== | ||
+ | |||
+ | These constraints are called ' | ||
+ | that properties must always verify a set of ' | ||
+ | |||
+ | Class constraints take two forms : property types and class assertions. | ||
+ | |||
+ | Each property type is defined in its own docblock, just before the definition of its property and | ||
+ | class assertions are defined in the class docblock (the block just before the class | ||
+ | definition). | ||
+ | |||
+ | Note that we don't define a specific constraint type for static properties. They | ||
+ | will be checked using the same syntax as dynamic properties. | ||
+ | |||
+ | === Property types === | ||
+ | |||
+ | Syntax: | ||
+ | |||
+ | < | ||
+ | /** @var < | ||
+ | </ | ||
+ | |||
+ | where < | ||
+ | |||
+ | === Class assertions === | ||
+ | |||
+ | These are defined in class docblocks. | ||
+ | |||
+ | Syntax: | ||
+ | |||
+ | < | ||
+ | * @invariant < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | |||
+ | == Execution == | ||
+ | |||
+ | Property types are checked before class assertions. | ||
+ | |||
+ | This set of constraints is checked : | ||
+ | |||
+ | * after the execution of the constructor, | ||
+ | * before destroying the object, even if no destructor exists. | ||
+ | * before and after execution of a public dynamic method. | ||
+ | |||
+ | Class constraints are executed before pre-conditions and/or after post-conditions. | ||
+ | |||
+ | == Scope == | ||
+ | |||
+ | These constraints are executed in the class scope (' | ||
+ | |||
+ | == Inheritance == | ||
+ | |||
+ | The same mechanism is used as with pre/ | ||
+ | checked only if explicitely called using ' | ||
+ | |||
+ | ==== Nested calls ==== | ||
+ | |||
+ | When a function or method is called from a DbC condition, its constraints are | ||
+ | not checked. | ||
+ | |||
+ | ==== Constraint violations ==== | ||
+ | |||
+ | When a DbC condition fails, an E_ERROR is raised, containing the file and line number of the failing condition. | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | What breaks, and what is the justification for it? | + | |
+ | None | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | List the proposed PHP versions that the feature will be included in. Use relative versions such as " | + | |
+ | As the plan is to implement this in a separate extension, it should | ||
===== RFC Impact ===== | ===== RFC Impact ===== | ||
==== To SAPIs ==== | ==== To SAPIs ==== | ||
- | Describe the impact to CLI, Development web server, embedded PHP etc. | + | |
+ | None | ||
==== To Existing Extensions ==== | ==== To Existing Extensions ==== | ||
- | Will existing extensions be affected? | + | |
+ | None | ||
==== To Opcache ==== | ==== To Opcache ==== | ||
- | It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP. | ||
- | Please explain how you have verified your RFC's compatibility with opcache. | + | None |
==== New Constants ==== | ==== New Constants ==== | ||
- | Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation. | + | |
+ | None | ||
==== php.ini Defaults ==== | ==== php.ini Defaults ==== | ||
- | If there are any php.ini settings then list: | + | |
- | * hardcoded default values | + | A boolean whose name is still undefined. |
- | * php.ini-development | + | |
- | * php.ini-production | + | * php.ini-development |
+ | * php.ini-production | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- | Make sure there are no open issues when the vote starts! | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
- | List existing areas/ | ||
- | This helps avoid any ambiguity, shows that you have thought deeply about the RFC' | + | When DbC is turned off, there' |
===== Future Scope ===== | ===== Future Scope ===== | ||
- | This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC. | + | |
+ | - Extend DbC to internal functions | ||
+ | - Add exception checks (using ' | ||
+ | - Extend type syntax (define a syntax for ranges, enums, etc) | ||
+ | - Implement static-only class constraints (to be called before and after executing a static or dynamic public method) | ||
+ | - Extend DbC to interfaces and traits | ||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | Include these so readers know where you are heading and can discuss the proposed voting options. | ||
- | State whether this project requires a 2/3 or 50%+1 majority | + | Required |
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
- | Links to any external patches and tests go here. | ||
- | If there is no patch, make it clear who will create | + | This should be implemented in a Zend extension, not in the core. This would be a perfect addition for XDebug. |
- | Make it clear if the patch is intended to be the final patch, or is just a prototype. | + | ===== References ===== |
- | ===== Implementation ===== | + | [[http:// |
- | After the project is implemented, | + | |
- | - the version(s) it was merged to | + | |
- | - a link to the git commit(s) | + | |
- | - a link to the PHP manual entry for the feature | + | |
- | ===== References ===== | + | [[https:// |
- | Links to external references, discussions or RFCs | + | |
+ | [[http:// | ||
- | ===== Rejected Features ===== | + | [[https:// |
- | Keep this updated with features that were discussed on the mail lists. | + |
rfc/dbc.1423050107.txt.gz · Last modified: 2017/09/22 13:28 (external edit)