Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.68 as permitted sender)
MIME-Version: 1.0
References: <CAP=4hCK5BYcUhDGtAHggkAysMZiuraOfBt3TWge0g46GcT0X8g@mail.gmail.com>
 <BN6PR02MB323425E29746D9C173CF67A0BF7A0@BN6PR02MB3234.namprd02.prod.outlook.com>
 <5edffc76-33e7-9f56-83ab-c9ca129040a7@gmx.de>
In-Reply-To: <5edffc76-33e7-9f56-83ab-c9ca129040a7@gmx.de>
Date: Sat, 9 Jun 2018 12:32:08 -0300
Message-ID: <CAEsg9X15vTJAUb-Grt=rV4FE-d5=emesg3a+mPRecsubxwe=UA@mail.gmail.com>
To: cmbecker69@gmx.de
Cc: Dmitry Stogov <dmitry@zend.com>, carusogabriel34@gmail.com, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d6c3ae056e37386c"
Subject: Re: [PHP-DEV] [VOTE] Make compact function reports undefined passedvariables
From: david.proweb@gmail.com (David Rodrigues)

--000000000000d6c3ae056e37386c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Em s=C3=A1b, 9 de jun de 2018 =C3=A0s 11:27, Christoph M. Becker <cmbecker6=
9@gmx.de>
escreveu:

> On 09.06.2018 at 12:03, Dmitry Stogov wrote:
>
> > compact(), extract(), parse_str() (with 1 argument) and
> get_defined_vars() are bad functions, because they access local variables
> indirectly.
>
> While I agree that extract() and parse_str() can be dangerous, I don't
> understand why compact() and get_defined_vars() are =E2=80=9Cbad=E2=80=9D=
.  If the issue
> is that these functions allow to access (local) variables by their name
> (given as string), that appears to be not uncommon in PHP; cf. variable
> variables and $GLOBALS.
>

=E2=80=8BAgree here. I think that compact() should be modified just to work=
 like
compact($a, $b, $c) instead of compact('a', 'b', 'c'). It is very useful
for template engines.
=E2=80=8B

>
> > They might be considered to be removed in the next major PHP version,
> despite of this fix.
>
> That would certainly require the RFC process, and in my opinion, a
> deprecation phase would be very appropriate.  Note that parse_str()
> without second argument is already deprecated as of PHP 7.2.0 and
> scheduled for removal in the next major version[1].
>
> [1]
> <
> https://wiki.php.net/rfc/deprecations_php_7_2?s[]=3Dparse&s[]=3Dstr#parse=
_str_without_second_argument
> >
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--=20
David Rodrigues

--000000000000d6c3ae056e37386c--