Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81777
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <00c101d04049$ca411ec0$5ec35c40$@tekwire.net>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com>
	<CAGa2bXbQsh4qWizf+1k15+BvdNGqjD8OCPGx7S=WAhCPqimXuA@mail.gmail.com>
	<CA+9eiLsnyoxPO7b3oQEN5RbqVE0K6o-01FQR7SYfZQD=QLka5Q@mail.gmail.com>
	<00c101d04049$ca411ec0$5ec35c40$@tekwire.net>
Date: Wed, 4 Feb 2015 11:25:06 +0400
Message-ID: <CA+9eiLtfpnBH4H_uyM5yZe8M2C_70XKgy3aJ7P6VwdOk0psnQQ@mail.gmail.com>
To: francois@tekwire.net
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Joe Watkins <krakjoe@php.net>, 
	PHP Internals <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3ea3c303f96050e3e162c
Subject: Re: [PHP-DEV] What do we need strict scalar type hints for?
From: dmitry@zend.com (Dmitry Stogov)

--001a11c3ea3c303f96050e3e162c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A7ois Laupretre <francois@tekwire.=
net>
wrote:

> > De : Dmitry Stogov [mailto:dmitry@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 a=
s
> 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 opco=
de
> 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=C3=A7ois
>
>
>

--001a11c3ea3c303f96050e3e162c--