> De : Dmitry Stogov [mailto:[email protected]]
> Hi Yasuo,
>
> You probably talk about https://wiki.php.net/rfc/expectations
> I wasn't the author of idea, I just helped with thoughts and implantation.
> I think it may be useful for PHP7.
In accordance with Yasuo's suggestions, couldn't we consider assertions as part
of a future implementation of the wider 'design by contract' concept ?
DbC could handle :
- function inputs : 'smart' built-in arguments types (keeping loose typing),
constraints on possible values
- function output : accepted return types/values
- assertions anywhere in the code
Function input/output validation would be done using built-in 'smart' types
('string', 'numeric', 'integer', etc), and, optionally, 'validator' functions.
These could validate any aspect about argument/return type and value. The key
point with DbC (as well as assertions) is that, as there's no constraint on
performance, validation can be very precise and can run in userland code.
For function input/output validation, I would extend the phpdoc syntax (keeping
compatibility with existing comments).
Another suggestion for assertions : if we hide it in comments (something
unusual like '//@@assert(...)'), we probably don't need to define an opcode and
it can be implemented as a standard function.
The question of whether DbC should replace or just supplement arg/return typing
remains open :).
What I suggest, if you agree, is that, even if we don't implement the whole DbC
concept now, we could already consider assertions as being part of it, and
rename zend.assertions to zend.dbc, assert.exceptions to dbc.exceptions, and
AssertException to DbcException.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
