[PHP-DEV] Re: [RFC] Don't automatically unserialize Phar metadata outside getMetadata()

Hi internals, I plan to start the vote for https://wiki.php.net/rfc/phar_stop_autoloading_metadata on 2020-07-21, in 6 days. I've created an implementation of this RFC that passes existing phar test cases ( https://github.com/php/php-src/pull/5855 ). If anyone has additional test cases,

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. > > > > As this proposal

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

Hi, Implement an interface and magic method to allow objects to represent false > (or empty) while still be valid instances of the custom object (type). > > https://wiki.php.net/rfc/objects-can-be-falsifiable < > https://wiki.php.net/rfc/objects-can-be-falsifiable> > > If you saw the latest from

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

Hi! Hey Larry, > > wrote: > > > 1) return null, which is a non-type, and thus you need to make the return > > type ?User or User|null, which means the caller *must* always check it's > > nullness. > > > > Allowing an object to falsify itself is a 4th, more type-safe option. > It > > lets you

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

On Wed, Jul 15, 2020 at 10:43 AM Marco Pivetta wrote: > > Hey Larry, > > On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield > wrote: > > > 1) return null, which is a non-type, and thus you need to make the return > > type ?User or User|null, which means the caller *must* always check it's > >

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

Hey Larry, On Wed, Jul 15, 2020 at 7:15 PM Larry Garfield wrote: > On Wed, Jul 15, 2020, at 11:59 AM, Marco Pivetta wrote: > > Hey Larry, > > > > > > > > On Wed, Jul 15, 2020 at 6:55 PM Larry Garfield > > wrote: > > > > > I disagree

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

On Wed, Jul 15, 2020, at 11:59 AM, Marco Pivetta wrote: > Hey Larry, > > > > On Wed, Jul 15, 2020 at 6:55 PM Larry Garfield > wrote: > > > I disagree entirely. The value of a Maybe over just null is > > > > 1) You can bind to it even if the result is empty; the

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

Hey Larry, On Wed, Jul 15, 2020 at 6:55 PM Larry Garfield wrote: > I disagree entirely. The value of a Maybe over just null is > > 1) You can bind to it even if the result is empty; the "if is null" check > gets abstracted away from the main code. > That's

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

On Wed, Jul 15, 2020, at 11:43 AM, Marco Pivetta wrote: > Hey Larry, > > On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield > wrote: > > > 1) return null, which is a non-type, and thus you need to make the return > > type ?User or User|null, which means the caller *must* always check it's > >

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

Hey Larry, On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield wrote: > 1) return null, which is a non-type, and thus you need to make the return > type ?User or User|null, which means the caller *must* always check it's > nullness. > > Allowing an object to falsify itself is a 4th, more type-safe

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

> > > I don't see how that would happen. What non-pathological case would allow > for $foo && !$foo == true? > > I suppose something a little less pathological would be `$collection && $collection->pop() && !$collection` which is still pretty icky (to me at least). The other implication is

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

On Wed, Jul 15, 2020, at 9:24 AM, David Rodrigues wrote: > I really appreciate any effort that can make PHP a more powerful language. > However, for this item, I believe it will generate much greater cognitive > complexity for new users (and I hate to assume that this is a problem, but > we have

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

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 interpreting a number formatted with a sign ("1e+100") or with decimals

[PHP-DEV] [RFC][WITHDRAWN] Strict operators directive

I'm withdrawing the "Strict operators directive" RFC in favor of alternative ways of solving issues with non-strict operators that don't use a directive, like https://wiki.php.net/rfc/string_to_number_comparison Arnold [Arnold Daniels - Chat @

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

I really appreciate any effort that can make PHP a more powerful language. However, for this item, I believe it will generate much greater cognitive complexity for new users (and I hate to assume that this is a problem, but we have to remember our roots). Why, for now a variable $x will be truth,

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

On Tue, Jul 14, 2020, at 11:48 PM, Matthew Brown wrote: > On Tue, 14 Jul 2020 at 19:59, Josh Bruce wrote: > > > Implement an interface and magic method to allow objects to represent > > false (or empty) while still be valid instances of the custom object (type). > > > >

[PHP-DEV] [VOTE] Allow trailing comma in closure use lists

Hi internals, Voting on https://wiki.php.net/rfc/trailing_comma_in_closure_use_list has started, and ends on 2020-07-29. This proposes allowing a single optional trailing comma in closure use lists. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

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

On Wed, Jul 15, 2020 at 10:56 AM Brent Roose wrote: > Hi Nikita > > Yes that would be nice, if it's not too much of a hassle. I'm only able to > test this in one or two large Laravel projects, so it would still be a > limited test. > > Kind regards > Brent > Done!

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

Hi Nikita Yes that would be nice, if it's not too much of a hassle. I'm only able to test this in one or two large Laravel projects, so it would still be a limited test. Kind regards Brent > On 15 Jul 2020, at 10:53, Nikita Popov wrote: > > On Wed, Jul 15, 2020 at 10:49 AM Brent Roose

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

On Wed, Jul 15, 2020 at 10:49 AM Brent Roose wrote: > Hi Nikita > > Is the ini setting available in current 7.4 builds? Is it documented > somewhere? I'd like to test this change in some of our projects. > We did not introduce an ini setting in PHP 7.4, I only used it for my own experiments.

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

Hi Nikita Is the ini setting available in current 7.4 builds? Is it documented somewhere? I'd like to test this change in some of our projects. Kind regards Brent > On 15 Jul 2020, at 10:28, Nikita Popov wrote: > > On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson

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

On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson wrote: > Den 2020-07-14 kl. 15:48, skrev Nikita Popov: > > On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov > wrote: > > > >> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov > wrote: > >> > >>> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski wrote: > >>> >

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

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” keyword (make > implicit explicit)? > This affects any place accepting namespaced names. The

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. I will have to delay the vote again. Over the next day or two I will implement the changes and see if there are any other surprises. If there are, I will be