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,

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

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

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 >

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

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: [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

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,

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, 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 > > >

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

[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] [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

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 >

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

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][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

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 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

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”

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

[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:

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

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