Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.142 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: Nikita Popov <nikita.ppv@gmail.com>, PHP internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Deprecations for PHP 7.1
Thread-Index: AQHRaknF+yaXUytXzkClLtZqVI+hXp8yVa0AgAAR4OM=
Date: Thu, 18 Feb 2016 22:45:28 +0000
Message-ID: <97CC6432-564B-4E28-B2DE-9C496FF1984D@zend.com>
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>,<56C63A8A.3030809@gmail.com>
In-Reply-To: <56C63A8A.3030809@gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 22:45:28.3924
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB297
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1
From: zeev@zend.com (Zeev Suraski)



> On 18 =E1=F4=E1=F8=D7 2016, at 23:42, Stanislav Malyshev <smalyshev@gmail=
.com> wrote:
>=20
> Hi!
>=20
>> I've created a bulk-deprecation RFC for PHP 7.1:
>> https://wiki.php.net/rfc/deprecations_php_7_1
>=20
> I like dropping php_errormsg. Last time I tried to make error
> suppression work more efficiently this was a major problematic thing
> AFAIR, and in general using magic variables that pop out of nowhere is
> not a good thing.

I think we need to try and get an idea for the popularity of it before depr=
ecating it, as well as get an idea for what kind of performance benefits it=
 would bring (price/performance for making this change).

> For __autoload I guess since it's incompatible with superior SPL
> mechanism it has to go too.

Agreed.

> I'm not sure about create_function() - while it is old, I don't see why
> we should break working code using it just because better option is
> available.

There's that, and there's the fact closures don't give you the same functio=
nality - as Andrea pointed out.  I think deprecating it and forcing people =
to rewrite their code differently (either with eval or with closures) doesn=
't make a whole lot of sense when create_function() works perfectly well.  =
In terms of security risks, if you use it like you use closures I don't thi=
nk it's any riskier.  If you need eval() for programmatically creating func=
tions - it would obviously be at the exact same risk levels.  So we're left=
 with marginal performance gains - as practically speaking you don't typica=
lly create thousands of functions dynamically in a given request.  If you d=
o, chances are you've already migrated to closures.

>=20
> With rand functions, I don't think we need to touch them. For some
> applications, low-key randomness is just fine - if you need to shuffle
> array of 20 elements or randomize unit test to ensure you're not testing
> same value all the time, low-quality randomness is completely fine. For
> other applications, there are superior solutions and everybody who needs
> them already uses them, but again I see no value in removing those
> functions. It would only cause more breakage and make adoption of new
> versions (already horrible) even slower.

I think the obvious option here is to make rand() and srand() aliases to ra=
nd_mt() and srand_mt(), unless I'm missing something very basic, unless I'm=
 missing something very basic here..?  I see zero reason to deprecate them =
and break so much code when we can simply 'upgrade' them at zero cost to bo=
th us and users.

I think that this is something we should try to do in general, by the way. =
 Deprecating is easy, upgrading is not - and we should strive to minimize c=
ode breaks as much as possible.  If we can reimplement an old functionality=
 in a new and better and seamlessly provide a painless upgrade experience w=
e should always prefer it to forcing the users to edit their code.

Zeev