The idea of that RFC was an ability to have zero-cost assert(). DbC is a much more bigger feature, it is interesting, but requires significant work.
Thanks. Dmitry. On Wed, Feb 4, 2015 at 10:11 AM, François Laupretre <franc...@tekwire.net> wrote: > > 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 > > >
