Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82279
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <04ac01d04467$f4259b90$dc70d2b0$@tekwire.net>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D7ED22.3080001@gmail.com>
	<CA+9eiLvn7BzfG5N+5Oca8pVO1OTzN9=jWof6NrVDfxvvu-XqPA@mail.gmail.com>
	<CAL=_i_m78Zo5euReKsvFfrLknFq7KEzoNnrrBefC987u+=+yHQ@mail.gmail.com>
	<CA+9eiLuUFiKwOR-BqQEmkQirpAMxgb0GE70Zz7h4WDsd1Me8FQ@mail.gmail.com>
	<CAGa2bXYDvdvRLiOpDk8EnvE00JE4x47SXB9fET4uO2Er_F6s_w@mail.gmail.com>
	<CAL=_i_=mGc_0u0YDCQ7Jiqn_ggyJmQSd_mk_snf7ArDpDXO53A@mail.gmail.com>
	<CA+9eiLur0DVGBNkzFkiTj3POL5B9H0D8=5wE-wuwN2O-FQZNyg@mail.gmail.com>
	<04ac01d04467$f4259b90$dc70d2b0$@tekwire.net>
Date: Mon, 9 Feb 2015 17:48:47 +0400
Message-ID: <CA+9eiLs=PNkOT-ajeCnaBhBHztWs8rf8VeLTKkjefCz9h90PWg@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Joe Watkins <pthreads@pthreads.org>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113399e689f7e8050ea80772
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--001a113399e689f7e8050ea80772
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 9, 2015 at 3:57 PM, Fran=C3=A7ois Laupretre <francois@tekwire.n=
et>
wrote:

> Hi Dmitry,
>
> > De : Dmitry Stogov [mailto:dmitry@zend.com]
> > Envoy=C3=A9 : lundi 9 f=C3=A9vrier 2015 12:05
> > =C3=80 : Joe Watkins
> > Cc : Yasuo Ohgaki; Stanislav Malyshev; PHP Internals
> > Objet : Re: [PHP-DEV] Design by Contract
> >
> > invariant is for classes only. It should be called before and/or after
> each
> > method to check object consistency.
> >
> > syntax with expressions may work if we put constraints before the
> function
> > body .
> >
> > function foo($a int): int
> >     require(expr1)
> >     require(expr2, msg)
> >     return(expr3)
> > {
> > }
>
> I understand you're defining an implementation based on assertions only,
> despite the fact that 'require' and 'return' are very ambiguous choices I=
MO.
>
> Did you take into account that, in many cases, this would revert to stric=
t
> type checking, due to the way is_xxx() functions are working ?
>
> If someone writes 'function tan($op) / require (is_float($op));' will he
> expect tan(1) to be rejected ? (we're back to Rasmus' complaint).
>

You'll get exactly what you write in constraint, no any predefined
semantic, no need to learn predefined rules.


>
> The same with is_int() and others, they're all based on zval types. Only
> is_numeric() is smarter and allows specifying a 'number' in the PHP way.
> Unfortunately, these functions are wrong as they don't fit with the way
> people are used to consider types in PHP. So, no easy way to say you can
> accept 1 or 1.0, let alone "1".
>
> That's why my proposal features assertions AND 'smart' argument types.
> Actually, types are more important than assertions because that's what
> people will use first. Primary use for assertions will be checking
> conditions between args. The same for properties and return type. Actuall=
y,
> I would say that most phpdoc-annotated code already contains most DbC
> constraints it needs. We just need to formalize and use them.
>

I think, people will use type hinting first (in a way they'll be
implemented in PHP-7).

Thanks. Dmitry.


> As others already said here, be it for type checking or DbC, we need a
> mechanism to interpret types the 'PHP' way, something between PHP
> permissive type juggling and strict zval-based typing. That's what I trie=
d
> to define.
>

> I understand the prevention against inserting PHP code in doc comments
> and, if I was designing the language from scratch, I wouldn't use such a
> design. But, considering every aspects of the problem, I still think it's
> the best compromise to add the feature.
>
> Regards
>
> Fran=C3=A7ois
>
>
>

--001a113399e689f7e8050ea80772--