> 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