Re: [VOTE] Deprecations for PHP 7.3

From: Date: Tue, 10 Jul 2018 16:54:18 +0000
Subject: Re: [VOTE] Deprecations for PHP 7.3
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-102721@lists.php.net to get a copy of this message
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>: > > 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 ownmy\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. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >

« previous php.internals (#102721) next »