Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100649
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAL0xaBH+7rMZMkFOaWZNASBg7r7QZkEnnUb3JVHTO6omTVjS2g@mail.gmail.com>
Date: Sat, 16 Sep 2017 02:42:41 +0700
Cc: Ryan Pallas <derokorian@gmail.com>, ilija.tovilo@me.com,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1261C0F4-C1C1-42BC-85AD-C6A851D5905B@koalephant.com>
References: <097578bf-ab74-44cf-a465-dc6fdd50930f@Spark> <CAObuZdtSUwyJi-qmg8cDjHJvqGtecTJ8U5J8tm_Oe765m5vDPw@mail.gmail.com> <ddd6a841-665f-461f-a29f-d9cbf1293927@Spark> <CAObuZdudduHyj+gf=rtEb+3xyEG+NGRuT=Xv7qcim-vdx7kvXA@mail.gmail.com> <CAL0xaBH+7rMZMkFOaWZNASBg7r7QZkEnnUb3JVHTO6omTVjS2g@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
From: php-lists@koalephant.com (Stephen Reay)


> On 16 Sep 2017, at 01:27, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:=

>=20
> 2017-09-15 20:52 GMT+03:00 Ryan Pallas <derokorian@gmail.com>:
>=20
>>> On Fri, Sep 15, 2017 at 11:38 AM, <ilija.tovilo@me.com> wrote:
>>>=20
>>> Hi Ryan
>>>=20
>>> I can see your argument. The reasoning behind it is that a function in
>> the
>>> standard library should not encourage unsafe code. Admittedly, since thi=
s
>>> function is rarely used except for templating systems one could call
>> this a
>>> non-issue. I just wanted to bring it up.
>>>=20
>>=20
>> That makes sense. What about performance difference? On a reasonable size=
d
>> array (not 10k items and not 2) which is faster?
>>=20
>> extract($array);
>>=20
>> - or -
>>=20
>> foreach ($array as $key =3D> $value)
>>    $$key =3D $value;
>>=20
>> Honestly, I don't know (ps 2 lines without braces instead of 3!)
>>=20
>>=20
>>>=20
>>> Regards
>>>=20
>>>=20
>>> On 15 Sep 2017, 19:30 +0200, Ryan Pallas <derokorian@gmail.com>, wrote:
>>>=20
>>>=20
>>>=20
>>> On Sep 15, 2017 11:22 AM, <ilija.tovilo@me.com> wrote:
>>>=20
>>> Hi!
>>>=20
>>> The `extract` function takes an associative array and puts it into the
>>> local symbol table.
>>> http://php.net/manual/en/function.extract.php
>>>=20
>>> ```
>>> $array =3D [
>>>    =E2=80=98foo=E2=80=99 =3D> =E2=80=98foo=E2=80=99,
>>>    =E2=80=98bar=E2=80=99 =3D> =E2=80=98bar=E2=80=99,
>>> ];
>>>=20
>>> extract($array);
>>>=20
>>> print $foo; // "foo"
>>> ```
>>>=20
>>> As a second parameter the `extract` function takes some options to make
>>> this function less dangerous, like `EXTR_SKIP` that prevents an existing=

>>> local variable of being overwritten. There=E2=80=99s a few more options,=
 go ahead
>>> and take a look at the documentation. `EXTR_OVERWRITE` is the default on=
e
>>> though. You can also pass a prefix for the variable names as a third
>>> argument.
>>>=20
>>> I seriously doubt the usefulness of this function, especially looking at=

>>> the potential risks. The fact that overwriting the local variables is th=
e
>>> default behaviour doesn=E2=80=99t make it any better. I suggest deprecat=
ing it in
>>> PHP 7.3 and removing it in 8.
>>>=20
>>> In a whole Symfony-Stack (3.4) with all of it=E2=80=99s dependencies I c=
ould only
>>> find two usages of this function, both of which could be easily rewritte=
n
>>> in vanilla PHP:
>>> https://github.com/symfony/symfony/blob/master/src/Symfony/
>>> Component/Templating/PhpEngine.php#L148
>>> https://github.com/symfony/symfony/blob/master/src/Symfony/
>>> Component/Templating/PhpEngine.php#L158
>>>=20
>>> Only downside: A polyfill is probably impossible since you cannot mutate=

>>> the local symbol table of the callee (as far as I=E2=80=99m aware).
>>>=20
>>> Any thoughts?
>>>=20
>>>=20
>>> I see no gain by removing this function. I've also seen it used for
>>> templating quite often. Yes the functionality could be changed not to us=
e
>>> extract and end up working the same to the consumer but why make people
>>> rewrite these things for no apparent gain (and likely a small performanc=
e
>>> hit)?
>>>=20
>>>=20
>>> Regards
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>=20
> Hi Ryan,
> well, basically, none. Results are from a Q6600 machine and under windows,=

> so your mileage probably gonna be quite better :)
>=20
> C:\Users\psihius\Documents\web>php -v
> PHP 7.1.5 (cli) (built: May  9 2017 19:48:36) ( NTS MSVC14 (Visual C++
> 2015) x64 )
> Copyright (c) 1997-2017 The PHP Group
> Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
> C:\Users\psihius\Documents\web>php -d memory_limit=3D-1 test.php
> 6.884626150131226 - Creating arrays
> 2.035606861114502 - foreach
> 2.128609180450439 - extract
>=20
> The code:
>=20
> define('ITERATIONS', 10000000);
>=20
> $__time =3D microtime(true);
>=20
> $__array =3D $__array2 =3D [];
> for ($__i =3D 0; $__i < ITERATIONS; ++$__i) {
>    $__array['a'.$__i] =3D $__i;
>    $__array2['b'.$__i] =3D $__i;
> }
> echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
>=20
> $__time =3D microtime(true);
> foreach ($__array as $__key =3D> $__variable) {
>    $$__key =3D $__variable;
> }
> echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
>=20
> $__time =3D microtime(true);
> foreach ($__array2 as $__key =3D> $__variable) {
>    $$__key =3D $__variable;
> }
> echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
>=20
> --=20
> Arv=C4=ABds Godjuks
>=20
> +371 26 851 664
> arvids.godjuks@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius

Hi all,

If you want to reduce unintended consequences while retaining functionality,=
 the default flag could be changed to EXTR_SKIP. Yes it affects BC but it's a=
lso much simpler to fix than if the functionality is gone completely, and in=
 the case of templating it's probably already used that way in most cases an=
yway.

Cheers


Stephen=20