Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82277
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@tekwire.net>
To: "'Dmitry Stogov'" <dmitry@zend.com>,
	"'Joe Watkins'" <pthreads@pthreads.org>
Cc: "'Yasuo Ohgaki'" <yohgaki@ohgaki.net>,
	"'Stanislav Malyshev'" <smalyshev@gmail.com>,
	"Rasmus Lerdorf" <rasmus@lerdorf.com>,
	"'PHP Internals'" <internals@lists.php.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>
In-Reply-To: <CA+9eiLur0DVGBNkzFkiTj3POL5B9H0D8=5wE-wuwN2O-FQZNyg@mail.gmail.com>
Date: Mon, 9 Feb 2015 13:57:24 +0100
Message-ID: <04ac01d04467$f4259b90$dc70d2b0$@tekwire.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGgxP9HPTh52uHWkGo6jLSeXRdtNAMgQV04AXznbe0C/KNi4gHjmxmHAVkKc8gBfNJbegGHSzWZnNhnnoA=
Content-Language: fr
Subject: RE: [PHP-DEV] Design by Contract
From: francois@tekwire.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

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
>=20
> invariant is for classes only. It should be called before and/or after =
each
> method to check object consistency.
>=20
> syntax with expressions may work if we put constraints before the =
function
> body .
>=20
> 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 =
IMO.

Did you take into account that, in many cases, this would revert to =
strict 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).

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. =
Actually, I would say that most phpdoc-annotated code already contains =
most DbC constraints it needs. We just need to formalize and use them.

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 =
tried 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