Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Deprecations for PHP 7.3 »

[VOTE] Deprecations for PHP 7.3

php.internals

Nikita Popov

8 years ago
Hi, I would like to start voting on the "Deprecation for PHP 7.3" RFC, which combines six minor deprecation proposals: https://wiki.php.net/rfc/deprecations_php_7_3 Each deprecation is voted separately and will require a 2/3 majority independently of whether it is a language or library change. The votes are open until 2018-07-16. You can read up on the discussion for this RFC here: https://externals.io/message/102394 Regards, Nikita

Marco Pivetta

8 years ago
Something unclear to me here: is the removal of `assert()` affecting also my own`my\assert()` (imported via `use function`)? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jul 9, 2018 at 10:47 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

Sara Golemon

8 years ago
On Mon, Jul 9, 2018 at 5:57 AM, Marco Pivetta <ocramius@gmail.com> wrote:
> Something unclear to me here: is the removal of `assert()` affecting also > my own`my\assert()` (imported via `use function`)? >
Yes, but in fairness, your namespaced assert function is already a bit broken if you're not expecting it to be elided in production environments. -Sara

Marco Pivetta

8 years ago
Alright, voted "NO" on that one then - namespaced stuff should have whichever symbol name without colliding with internals Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jul 9, 2018 at 4:42 PM, Sara Golemon <pollita@php.net> wrote:

Levi Morrison

8 years ago
On Mon, Jul 9, 2018 at 8:43 AM Sara Golemon <pollita@php.net> wrote:
> > On Mon, Jul 9, 2018 at 5:57 AM, Marco Pivetta <ocramius@gmail.com> wrote: > > Something unclear to me here: is the removal of `assert()` affecting also > > my own`my\assert()` (imported via `use function`)? > > > Yes, but in fairness, your namespaced assert function is already a bit > broken if you're not expecting it to be elided in production > environments. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Can you prove this somehow? Based on how `use function my\assert;` works a call to `assert()` later in that file should appear to engine as `my\assert`, not `assert`.

Sara Golemon

8 years ago
On Mon, Jul 9, 2018 at 11:18 AM, Levi Morrison <levim@php.net> wrote:
> Can you prove this somehow? Based on how `use function my\assert;` > works a call to `assert()` later in that file should appear to engine > as `my\assert`, not `assert`. >
The vote is on deprecating (and ultimately blocking) the *declaration* of the assert function in any namespace. How the call looks is immaterial to that. Unless you're asking about the elision, in which case... you're right, that appears to not happen anyway, so I'll doubly stand by my vote against deprecating this based on implementation details. -Sara

Niklas Keller

8 years ago
I put that item onto the list. The author of https://github.com/mikey179/bovigo-assert originally had the issue that a function named `assert` behaves really weird. `assert()` in namespaced code might refer to the namespaced `assert()` function, but might also fall back to the global `assert()`. Whether the function is jumped around or not depends on `zend.assertions`, which is highly surprising, because it also jumps around `assert()` in namespaced code even if an `assert()` function exists in that namespace. Requiring an explicit `use function` is really weird. See https://3v4l.org/8EKdA for an example. The behavior in PHP 7.0+ is by-design and mentioned in the original assertions RFC. Regards, Niklas Am Mo., 9. Juli 2018 um 17:18 Uhr schrieb Levi Morrison <levim@php.net>:

Nikita Popov

8 years ago
On Mon, Jul 9, 2018 at 10:47 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi, > > I would like to start voting on the "Deprecation for PHP 7.3" RFC, which > combines six minor deprecation proposals: > > https://wiki.php.net/rfc/deprecations_php_7_3 > > Each deprecation is voted separately and will require a 2/3 majority > independently of whether it is a language or library change. The votes are > open until 2018-07-16. > > You can read up on the discussion for this RFC here: > https://externals.io/message/102394 > > Regards, > Nikita >
I'm happy to announce that all parts of this RFC have been accepted, with the following voting breakdown: * mbstring aliases: 37 in favor, 1 against * non-string needles: 32 in favor, 1 against * fgetss and co: 20 in favor, 4 against * assert redeclaration: 20 in favor, 7 against * FILTER_FLAG_(SCHEME|HOST)_REQUIRED: 31 in favor, 1 against * pdo_odbc.db2_instance_name: 29 in favor, 0 against Nikita