Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On 17/07/2020 04:49, Levi Morrison via internals wrote: I don't care to debate it. I will just vote no. Fair enough, however the point of the internals mailing list and discussion period is to debate the RFCs :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Thu, Jul 16, 2020 at 9:29 PM Mark Randall wrote: > > On 17/07/2020 02:58, Levi Morrison via internals wrote: > >2. I don't think this is solving any problems, really: > > - Code can move from PHP land to an extension and back again. > > Should the namespace change just because it moved

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On 17/07/2020 02:58, Levi Morrison via internals wrote: 2. I don't think this is solving any problems, really: - Code can move from PHP land to an extension and back again. Should the namespace change just because it moved one way or the other? I vote no. This is not what the RFC propos

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield wrote: > > After some discussion, the namespacing proposal has been again updated. Two > major changes: > > 1) Only engine code goes in \PHP. There's a separate \Ext namespace for > extensions, whether bundled or PECL. > > 2) It establishes that a

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

After some discussion, the namespacing proposal has been again updated. Two major changes: 1) Only engine code goes in \PHP. There's a separate \Ext namespace for extensions, whether bundled or PECL. 2) It establishes that an index will be maintained on the Wiki listing what namespaces are a

[PHP-DEV] PR: Bump libxml version, deprecate libxml_disable_entity_loader()

Hi internals, I prepared a PR which aims to properly fix a long standing problem related to secure XML processing in PHP. In short, it bumps the minimum required version of libxml and it deprecates the libxml_disable_entity_loader() function. You can find the details in the PR: https://github.c

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

On Thu, Jul 16, 2020 at 3:00 PM Theodore Brown wrote: > On Thu, July 16 2020 at 3:04 AM Nikita Popov wrote: > > > While I don't think anyone had plans to mix whitespace, this is > > indicative of a larger issue. While I'm one of the people who voted > > for @@ as my first choice before, I wouldn

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

> On Jul 16, 2020, at 10:28 AM, Josh Bruce wrote: > > https://wiki.php.net/rfc/objects-can-be-falsifiable > > > Updates: > > - Open issues (outstanding questions/concerns) updated > - Future scope > - References now have links to original

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

> On Jul 15, 2020, at 3:26 AM, Nikita Popov wrote: > > On Tue, Jul 14, 2020 at 5:37 PM Josh Bruce > wrote: > New to the discussion and being this deep; so, apologies for any bumps. > Mainly questions. > > Does this only affect the string after the “namespace” keywor

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

https://wiki.php.net/rfc/objects-can-be-falsifiable Updates: - Open issues (outstanding questions/concerns) updated - Future scope - References now have links to original copies on GitHub (still updating 0002) - will be removed if accepted a

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

On 16/07/2020 15:43, Nikita Popov wrote I haven't backported any deprecation warnings to 7.4. Adding deprecations to released versions is a hard no-go. My apologies. I'd got my wires crossed with seeing https://github.com/php/php-src/pull/3917 appear on the PRs. -- PHP Internals - PHP Runti

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

On Thu, Jul 16, 2020 at 4:35 PM Mark Randall wrote: > On 16/07/2020 16:15, G. P. B. wrote: > > I do agree that accepting trailing whitespace may be considered > suboptimal > > but as leading whitespaces don't even emit an E_NOTICE it is impossible > to > > drop this "feature". > > Didn't someone

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

On 16/07/2020 16:15, G. P. B. wrote: I do agree that accepting trailing whitespace may be considered suboptimal but as leading whitespaces don't even emit an E_NOTICE it is impossible to drop this "feature". Didn't someone (Nikita?) already back-port a warning to 7.4 about some changes coming

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

On Thu, 16 Jul 2020 at 15:39, Marco Pivetta wrote: > Hey George, > > I really like this specific bit of the proposal: > > > And the various cases which currently emit an E_WARNING will be > promoted to TypeErrors. > > I really do not like these particular horrible behaviors of the language > (hu

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

Hey George, I really like this specific bit of the proposal: > And the various cases which currently emit an E_WARNING will be promoted to TypeErrors. I really do not like these particular horrible behaviors of the language (huge "yikes" for PHP being so broken): * `"123" == "123 "` - do not

[PHP-DEV] [RFC] [VOTE] Saner numeric strings

Hello internals, I've opened voting for the Saner Numeric strings RFC: https://wiki.php.net/rfc/saner-numeric-strings This will last 2 weeks until the 30th of July Best regards George P. Banyard

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

On Thu, July 16 2020 at 3:04 AM Nikita Popov wrote: > While I don't think anyone had plans to mix whitespace, this is > indicative of a larger issue. While I'm one of the people who voted > for @@ as my first choice before, I wouldn't do so now (even with > this RFC accepted). This issue made me

Re: [PHP-DEV] Re: [RFC] Nullsafe operator

Hi internals > > https://wiki.php.net/rfc/nullsafe_operator > > Unfortunately, we have found some new edge cases that are currently > not handled. So, we've decided to completely disallow the nullsafe operator in write context. This means you can no longer use it on the left hand side of an assig

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

> > > > I have reduced the scope of this RFC to handle just the issue of > > > > namespaced names, without touching any other reserved keyword > > restrictions. > > > > As the discussion shows, those are trickier, with more cases of > > perceived > > > > ambiguity that may need to be mitigated. > >

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

On Thu, 16 Jul 2020 at 09:04, Nikita Popov wrote: > While I don't think anyone had plans to mix whitespace, this is indicative > of a larger issue. While I'm one of the people who voted for @@ as my first > choice before, I wouldn't do so now (even with this RFC accepted). This > issue made me re

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

On Thu, Jul 16, 2020 at 3:40 AM tyson andre wrote: > > > I have reduced the scope of this RFC to handle just the issue of > > > namespaced names, without touching any other reserved keyword > restrictions. > > > As the discussion shows, those are trickier, with more cases of > perceived > > > amb

Re: [PHP-DEV] [RFC] Saner string to number comparisons

On Thu, Jul 16, 2020 at 9:21 AM Brent Roose wrote: > Hey Nikita > > Thanks for the rebase. I just tested this on one of our most largest > projects (after verifying that the warning does show in a dummy test case), > and all is fine. So from my point of view, there is a theoretical chance of > br

Re: [PHP-DEV] [RFC] Saner string to number comparisons

On Wed, Jul 15, 2020 at 5:12 PM Arnold Daniels wrote: > Hi Nikita, > > One of the problems with numeric string comparisons is that it might > interpret a hexadecimal value as scientific notation > > $red = '99'; > $purple = '9900e2'; > $red == $purple; // true > > I suggest only i

Re: [PHP-DEV] [RFC] Saner string to number comparisons

Hey Nikita Thanks for the rebase. I just tested this on one of our most largest projects (after verifying that the warning does show in a dummy test case), and all is fine. So from my point of view, there is a theoretical chance of breaking code, but I believe this won't have a large impact, at