> De : Dmitry Stogov [mailto:dmi...@zend.com]
> 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

Reply via email to