Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

> On Jun 15, 2021, at 6:53 AM, Nikita Popov wrote: > > As we're moving closer to feature freeze, I'd like to close down this RFC > to further additions, and move towards voting. > > Feedback on the proposed deprecations is appreciated. Personally, the two > I'm unsure about are "get_class(),

Re: [PHP-DEV] [RFC] New in initializers

> On Jun 15, 2021, at 11:06 AM, Nikita Popov wrote: > > On Fri, Jun 11, 2021 at 5:02 PM Larry Garfield > > wrote: > >> On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote: >>> Hi internals, >>> >>> I would like to propose allowing the use of "new" inside various

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

On 16 June 2021 00:19:14 BST, tyson andre wrote: >> Maybe better use "IterableImmutable" to be more consistent with >"DateTimeImmutable"? > >1. Replies won't show up on list if they aren't sent to >internals@lists.php.net >2. I consider the name DateTimeImmutable a mistake (but one that isn't

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

Hi Thomas Bley, > Maybe better use "IterableImmutable" to be more consistent with > "DateTimeImmutable"? 1. Replies won't show up on list if they aren't sent to internals@lists.php.net 2. I consider the name DateTimeImmutable a mistake (but one that isn't worth fixing). If it was done from

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

Hi Marco Pivetta, > I see the RFC as valuable but: > > * `__serialize` and `__unserialize` are out of scope: this depends on the >contents of it, and there's no point in implementing them > * `__set_state` should also not be implemented: `var_export()` like any other >object and it should be

Re: [PHP-DEV] [RFC][Draft] Add json_encode indent parameter

On Mon, Jun 7, 2021 at 11:53 AM Nikita Popov wrote: > On Thu, Jun 3, 2021 at 6:11 PM Timon de Groot > wrote: > > > Hi internals, > > > > I'd like to present my RFC for adding the indent parameter to the > > json_encode function: > >https://wiki.php.net/rfc/json_encode_indentation > > > >

Re: [PHP-DEV] Rename Fiber::this() to Fiber::getCurrent()

This doesn't look like the sort of detail we need to vote on. It would be nice if this were made in time for the migration guide and other doc to be prepared for 8.1. Let's move forward, please ... Cheers Joe On Tue, 15 Jun 2021 at 21:54, Larry Garfield wrote: > On Tue, Jun 15, 2021, at 2:01

Re: [PHP-DEV] Rename Fiber::this() to Fiber::getCurrent()

On Tue, Jun 15, 2021, at 2:01 PM, Aaron Piotrowski wrote: > Hi all, > > During the Fiber RFC vote, several people noted that they objected to > the name Fiber::this() for the method returning the currently executing > Fiber object. > > I'd like to propose renaming this method to

[PHP-DEV] Rename Fiber::this() to Fiber::getCurrent()

Hi all, During the Fiber RFC vote, several people noted that they objected to the name Fiber::this() for the method returning the currently executing Fiber object. I'd like to propose renaming this method to Fiber::getCurrent(). A simple PR for the rename:

Re: [PHP-DEV] [Vote] Short functions

On Mon, May 31, 2021, at 4:05 PM, Larry Garfield wrote: > Hello again. I have also opened the vote for short-functions. > > https://wiki.php.net/rfc/short-functions > > The vote closes Monday 14 June. The vote has now closed. Final tally: Yes: 16 No: 18 The RFC has not passed. Thank you

Re: [PHP-DEV] [RFC] New in initializers

On Tue, Jun 15, 2021, at 10:06 AM, Nikita Popov wrote: > On Fri, Jun 11, 2021 at 5:02 PM Larry Garfield > wrote: > > > On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote: > > > Hi internals, > > > > > > I would like to propose allowing the use of "new" inside various > > > initializer

Re: [PHP-DEV] [RFC] New in initializers

On Fri, Jun 11, 2021 at 5:02 PM Larry Garfield wrote: > On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote: > > Hi internals, > > > > I would like to propose allowing the use of "new" inside various > > initializer expressions: https://wiki.php.net/rfc/new_in_initializers > > > > In particular,

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1

Hello, Le Tue, 15 Jun 2021 12:53:47 +0200, Nikita Popov a écrit : > Feedback on the proposed deprecations is appreciated. Personally, the two > I'm unsure about are "get_class(), get_parent_class() and > get_called_class() without argument" which are mostly stylistic in nature, > and "strftime()

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

Hey Tyson, On Tue, Jun 15, 2021 at 4:01 PM tyson andre wrote: > Hi internals, > > Voting has started on the ImmutableIterable RFC > https://wiki.php.net/rfc/cachediterable > > Previous discussion can be found in https://externals.io/message/114834 > > Recent

[PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

Hi internals, Voting has started on the ImmutableIterable RFC https://wiki.php.net/rfc/cachediterable Previous discussion can be found in https://externals.io/message/114834 Recent changes: - The name was renamed to `ImmutableIterable` to indicate that it cannot be changed after being

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

thanks > Not going to include a deprecation proposal as part of this RFC though -- from past discussions, the topic was controversial, so I don't want to include it this late in the process. That's fine by me. > the topic was controversial indeed it is/was (at least on Reddit) On Tue, 15 Jun

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan wrote: > i don't like this part of the RFC: > > > There's a number of bug reports related to this. From what I understand, > the core problem here is not that the ISO8601 format is *wrong*, it's just > one of multiple legal ISO-8601 formats. As

[PHP-DEV] Re: [RFC] Deprecations for PHP 8.1

On Mon, Mar 22, 2021 at 10:24 AM Nikita Popov wrote: > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > > This is a collection of minor deprecations that various people have put > together over the last ~2 years. This RFC was formerly

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

i don't like this part of the RFC: > There's a number of bug reports related to this. From what I understand, the core problem here is not that the ISO8601 format is *wrong*, it's just one of multiple legal ISO-8601 formats. As DateTime formats always refer to a specific format, not a set of

Re: [PHP-DEV] [RFC] is_literal

On 15/06/2021 08:19, Joe Watkins wrote: https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe. It's possible to create more

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

On 23.03.2021 at 06:04, Stanislav Malyshev wrote: >> t fopen mode > > I'm afraid there's - despite the warning - a bunch of code for Windows > that relies on "t" and I don't think we should be breaking it. Is there > a good reason to drop this mode? I don't see much need for 't' mode nowadays.

Re: [PHP-DEV] [RFC] is_literal

Hi, It's not unpredictable. krakjoe@Fiji:/opt/src/php-src$ cat nothing.php krakjoe@Fiji:/opt/src/php-src$ var=not-literal sapi/cli/php nothing.php string(11) "not-literal" bool(false) The engine doesn't intern "randomly", and doesn't intern input. Cheers Joe On Tue, 15 Jun 2021 at 10:56,

Re: [PHP-DEV] [RFC] is_literal

> Le 15 juin 2021 à 09:19, Joe Watkins a écrit : > > Morning, > > https://3v4l.org/nJhc1/rfc#focus=rfc.literals > > > It's not so much a bug as a side effect or quirk. > > Note that, the result is correct, in the sense that you do have a

Re: [PHP-DEV] Allow objects in define()

On Tue, Jun 15, 2021 at 8:44 AM Claude Pache wrote: > > > > Not sure about specific use cases, for me the important aspect here is to > avoid arbitrary restrictions. For example, define() accepts resources, and > this is used for some core constants like STDIN, STDOUT, STDERR. > > > Per the

Re: [PHP-DEV] [RFC] is_literal

Morning, https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe. It's just that existing implementation details - RETURN_CHAR

Re: [PHP-DEV] [VOTE] Deprecate autovivification on false

Hi Kamil, PHP warnings are tricky, error handlers may cause side effects, throw exceptions, etc. Especially, for this deprecation you'll have to handle a new "slow" path (in VM and JIT) that should return back to the main path. Thanks. Dmitry. On Fri, Jun 11, 2021 at 3:13 PM Kamil Tekiela

Re: [PHP-DEV] Allow objects in define()

> > Not sure about specific use cases, for me the important aspect here is to > > avoid arbitrary restrictions. For example, define() accepts resources, > and > > this is used for some core constants like STDIN, STDOUT, STDERR. > > > > Per the documentation [1], defining resource constants is

Re: [PHP-DEV] Allow objects in define()

> > Not sure about specific use cases, for me the important aspect here is to > avoid arbitrary restrictions. For example, define() accepts resources, and > this is used for some core constants like STDIN, STDOUT, STDERR. > Per the documentation [1], defining resource constants is supposed to