Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83535
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Lester Caine'" <lester@lsces.co.uk>,
	"'PHP internals'" <internals@lists.php.net>
References: <54EA7BDC.7000002@lsces.co.uk>
In-Reply-To: <54EA7BDC.7000002@lsces.co.uk>
Date: Mon, 23 Feb 2015 03:49:07 +0100
Message-ID: <06d601d04f13$4b0f2100$e12d6300$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLAq8ojwQY12Chy7AsQOev7yTKvF5scwnlQ
Content-Language: fr
Subject: RE: [PHP-DEV] Type hints ...
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi Lester,

I am not sure I understand well, but the extended type syntax partially =
described in https://wiki.php.net/rfc/dbc may correspond to what you =
describe. Such extended syntax will be part of 'Design by Contract', =
meaning it's potentially too slow to run in production and checks can be =
turned on and off globally. When it is available, PHP argument type =
hints will become simplified fast checks that run every time, even in =
production.

Extended types will support nested syntax as complex as =
'object(Iterable)|array('id' =3D> int(]0:), * =3D> =
string|array(string))'. No limit to the syntax you may support here. It =
will also be available as a dynamic feature which will allow to check a =
variable against a dynamically-defined type. *This* will bring dramatic =
performance improvement in data validation. I don't imagine type hints =
will bring much in terms of overall performance.

I guess that's what you mean but please confirm. I think this will be my =
next project for PHP, after STH if it passes.

Regards

Fran=C3=A7ois

> De : Lester Caine [mailto:lester@lsces.co.uk]
>
> Currently I have an array of variables and the docblock annotation =
tells
> me just what each element is intended to be. I process the variables =
on
> that basis and while it may be helpful to have some higher level of
> 'restraint', I have a working flexible system. As a variable is
> processed it is constrained by the appropriate rules. If PHP adds =
'Type
> Hints' they will only apply to where I am passing an array variable, =
and
> the type hint adds additional processing to that which I already
> maintain myself. How will that improve performance?

It won't, except if you remove some redundant checks from your PHP code. =
Type checks performed by STH are faster than the equivalent PHP code, =
that's the only possible performance improvement I imagine.

> Add to this equation that the type and constraints of a variable may
> well vary from one record set to another. It may well be that a fixed
> set of types can be defined, but these are not the types currently =
being
> defined and would include date types in parallel with a group of =
numeric
> types.
>=20
> Passing 'strict' types in some cases just does not compute in my book,
> and even 'coercive' types only addresses a subset of the types needed =
so
> that it adds another layer of 'checking' over what we already have in
> much of the existing user code base. People keep going on about
> different rule sets but this just adds another set of 'rules' rather
> than a single solution.
>=20
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php