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

[Mike Schinkel]

> 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(), get_parent_class() and
> get_called_class() without argument" which are mostly stylistic in nature,
> and "strftime() and gmtstrftime()", where the non-portability issues are
> possibly not so bad that a disruption of existing users is worthwhile.

I just opened one client project and searched and found 52 usages for 
get_called_class(), no usages for the other two.  Just one project.

This was a WordPress project which means many plugins from any different 
developers.

Would deprecating get_called_class() w/o a parameter be important enough to 
cause so much BC breakage?

-Mike

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

[Mike Schinkel]

> 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
>>> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>>> 
>>> In particular, this allows specifying object default values for
>> properties
>>> and parameters, and allows the use of objects as attribute arguments.
>>> 
>>> The RFC is narrow in scope in that it only adds support for "new". An
>>> extension to other call kinds should be straightforward though.
>>> 
>>> Regards,
>>> Nikita
>> 
>> Hi Nikita.  What's the status of this RFC?  Are you going to bring it to a
>> vote, or is something else blocking it?
>> 
> 
> I've just pushed a larger update to the RFC, which limits the places where
> new is supported.
> 
> Supported:
> * Parameter default values (includes promoted properties)
> * Attribute arguments
> * Static variable initializers
> * Global constant initializers
> 
> Not supported:
> * Static and non-static property initializers
> * Class constant initializers

And I am saddened by the lack of class constant initializers.  That's the main 
use case I am interested in and I had been watching this RFC anxiously for that 
one reason. .  (In particular, because it would allow me to assign classes to 
constants with __ToString() methods to lazy load information.)

> I believe the cases that are now supported should be completely unambiguous
> and uncontroversial.

Well, at least it is the former.  :-)

-Mike

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

[Derick Rethans]

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
>worth fixing).
>If it was done from scratch I believe ImmutableDateTime would make more
>sense with the adjective first, then the noun.

No. If it was done from scratch, we'd only have DateTime, which would be 
immutable. 

cheers, 
Derick 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tyson andre]

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 scratch I believe ImmutableDateTime would make more 
sense with the adjective first, then the noun.

https://www.php.net/recursiveiterator 
https://www.php.net/manual/en/class.cachingiterator.php
https://www.php.net/manual/en/class.splpriorityqueue.php etc

Regards,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tyson andre]

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 fine
> * `jsonSerialize` also depends on the contents, and shouldn't be exposed
> 
> All of this is not part of what should be in a reusable iterator.

This is an IteratorAggregate implementation and all of the contents of the 
inner iterable are eagerly evaluated in the constructor.
I'd also considered names such as ImmutableIteratorAggregate, 
ImmutableKeyValueSequence or ImmutableEntrySet, but was unhappy with all of the 
names (excessively long, misleading, ambiguous, etc),
and prior discussion on the mailing list lead me to believe short names were 
widely preferred over long names https://externals.io/message/114834#114812

If it was lazily evaluated such as proposed in 
https://wiki.php.net/rfc/cachediterable#future_scope , I'd agree that 
`__serialize`, `__unserialize`, `json_encode`, etc likely didn't belong in a 
lazily evaluated data structure,
but the goal was creating a reusable data structure
(e.g. that could be used to store key-value sequences from any source compactly 
(e.g. generators) and be serialized
and persisted to memcached, redis, a file, static array, etc)

Cheers,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Jakub Zelenka]

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
> >
> > The `string|int $indent = 4` parameter adds the ability to specify the
> > indentation for
> > the JSON encoder. Amount of spaces can be specified by a number and a
> > string can be
> > specified to set a custom indentation like `\t` or whatever.
> >
> > As this is my first RFC (and contribution) for PHP, I'm all kind of new
> > to the process, standards, etc.
> > Please let me know if I could do something better.
> >
> > Looking forward to feedback/input on the RFC.
> >
>
> As has been brought up in
> https://github.com/php/php-src/pull/7093#issuecomment-855170601, the
> string
> version of the $indent parameter allows you to create invalid JSON,
> something that json_encode() does not currently allow. I tend to agree that
> it would make sense to validate that the indent only contains whitespace
> characters, and not .
>
>
I agree with this, it should validated to be also consistent with UTF-8
validation. For example if it's not valid utf8, it returns false (unless
ignoring or substitution is enabled). In any case it never returns invalid
json atm. I don't think it's a good idea to break that assumption.

Cheers

Jakub

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

[Joe Watkins]

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 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 Fiber::getCurrent(). A
> > simple PR for the rename: https://github.com/php/php-src/pull/7155
> > Nothing has functionally changed about the method, only the name.
> >
> > Fiber::current() is another possibility, but was not chosen because it
> > may be conflated with Iterator::current().
> >
> > Does anyone object to this rename? Shall we have a vote or is that not
> > necessary?
> >
> > Cheers,
> > Aaron Piotrowski
>
> I support this change, and don't think it needs an RFC.  I would vote for
> it if it were necessary, though.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

[Larry Garfield]

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 Fiber::getCurrent(). A 
> simple PR for the rename: https://github.com/php/php-src/pull/7155
> Nothing has functionally changed about the method, only the name.
> 
> Fiber::current() is another possibility, but was not chosen because it 
> may be conflated with Iterator::current().
> 
> Does anyone object to this rename? Shall we have a vote or is that not 
> necessary?
> 
> Cheers,
> Aaron Piotrowski

I support this change, and don't think it needs an RFC.  I would vote for it if 
it were necessary, though.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Aaron Piotrowski]

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: https://github.com/php/php-src/pull/7155
Nothing has functionally changed about the method, only the name.

Fiber::current() is another possibility, but was not chosen because it may be 
conflated with Iterator::current().

Does anyone object to this rename? Shall we have a vote or is that not 
necessary?

Cheers,
Aaron Piotrowski

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Larry Garfield]

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 everyone for your participation.

The patch had some lexer cleanup in it that I think is worth doing anyway, so I 
will file a new patch with just that cleanup shortly for review.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Larry Garfield]

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 expressions: https://wiki.php.net/rfc/new_in_initializers
> > >
> > > In particular, this allows specifying object default values for
> > properties
> > > and parameters, and allows the use of objects as attribute arguments.
> > >
> > > The RFC is narrow in scope in that it only adds support for "new". An
> > > extension to other call kinds should be straightforward though.
> > >
> > > Regards,
> > > Nikita
> >
> > Hi Nikita.  What's the status of this RFC?  Are you going to bring it to a
> > vote, or is something else blocking it?
> >
> 
> I've just pushed a larger update to the RFC, which limits the places where
> new is supported.
> 
> Supported:
>  * Parameter default values (includes promoted properties)
>  * Attribute arguments
>  * Static variable initializers
>  * Global constant initializers
> 
> Not supported:
>  * Static and non-static property initializers
>  * Class constant initializers
> 
> I believe the cases that are now supported should be completely unambiguous
> and uncontroversial. The other cases have evaluation order issues in one
> way or another. This is discussed in
> https://wiki.php.net/rfc/new_in_initializers#unsupported_positions.

Thanks, Nikita.  I would vote for this as is, but I am saddened by the lack of 
static property initializers.  That's the main use case I am interested in.  
(In particular, because sealed classes plus new-in-static-property would allow 
for something substantially similar to tagged unions, just not built on enums, 
and the latter is not making it into 8.1 it looks like.)

Arguments and attributes are enough to justify this RFC on its own, but is 
there a way we can resolve the static property question?  Right now the RFC 
says "these initializers are evaluated lazily the first time a class is used in 
a certain way."  Can you be more specific about that certain way?  Is there a 
certain way that would be minimally disruptive?

Also, I think there's a typo in the preceding paragraph about property 
initializers.  It says "the disciplined invocation of such constructors from 
potential parent constructors."  Shouldn't that be potential child constructors?

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Nikita Popov]

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, this allows specifying object default values for
> properties
> > and parameters, and allows the use of objects as attribute arguments.
> >
> > The RFC is narrow in scope in that it only adds support for "new". An
> > extension to other call kinds should be straightforward though.
> >
> > Regards,
> > Nikita
>
> Hi Nikita.  What's the status of this RFC?  Are you going to bring it to a
> vote, or is something else blocking it?
>

I've just pushed a larger update to the RFC, which limits the places where
new is supported.

Supported:
 * Parameter default values (includes promoted properties)
 * Attribute arguments
 * Static variable initializers
 * Global constant initializers

Not supported:
 * Static and non-static property initializers
 * Class constant initializers

I believe the cases that are now supported should be completely unambiguous
and uncontroversial. The other cases have evaluation order issues in one
way or another. This is discussed in
https://wiki.php.net/rfc/new_in_initializers#unsupported_positions.

Regards,
Nikita

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

[Côme Chilliet]

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() and gmtstrftime()", where the non-portability issues are
> possibly not so bad that a disruption of existing users is worthwhile.

I use get_called_class() a lot, which is way clearer than static::class as the
 name describe what it does.
I think I am not the only one as I find occurences of it in several projects I
 have in my vendor/ folder, like rector and codesniffer (not the latest version
 through, maybe they changed it).

Forcing people to use static::class will make them have a better
 understanding/instinct of what static:: does, but is that worth forcing a
 change on a working code for something less descriptive, I’m not convinced.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Marco Pivetta]

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 changes:
> - The name was renamed to `ImmutableIterable` to indicate that it cannot
> be changed after being constructed.
>   It was brought up in previous discussions that the previous name of
> `CachedIterable` could easily be assumed to have functionality similar to
> on-demand iterators/iterables such as https://php.net/cachingiterator
>   (Additionally, immutability is rare among spl data structures)
> - `__set_state` was added
>

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 fine
 * `jsonSerialize` also depends on the contents, and shouldn't be exposed

All of this is not part of what should be in a reusable iterator.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[tyson andre]

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 constructed.
  It was brought up in previous discussions that the previous name of 
`CachedIterable` could easily be assumed to have functionality similar to 
on-demand iterators/iterables such as https://php.net/cachingiterator
  (Additionally, immutability is rare among spl data structures)
- `__set_state` was added

Thanks,
Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Hans Henrik Bergan]

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 2021 at 14:24, Nikita Popov  wrote:

> 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 DateTime formats always refer
>> to
>> a specific format, not a set of multiple possible ones, there doesn't seem
>> to be anything actionable here.
>>
>> - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601.
>> quoting ISO8601:2004 section 4.3.3:
>>
>> > For reduced accuracy, decimal or expanded representations of date and
>> time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3
>> (ordinal dates) or 4.1.4 (week dates) followed immediately by the time
>> designator [T] may be combined with any of the representations in 4.2.2.2
>> through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local time
>> and
>> the difference from UTC) provided that (...skipped stuff...) d) the
>> expression shall either be completely in basic format, in which case the
>> minimum number of separators necessary for the required expression is
>> used,
>> or completely in extended format, in which case additional separators
>> shall
>> be used in accordance with 4.1 and 4.2.
>>
>> DateTime::ISO8601 does exactly what part "d" says isn't legal,
>> 1970-01-01T01:00:00 is extended format, and +0100 is basic format,
>> breaking
>> the "the expression shall either be completely in basic format, in which
>> case the minimum number of separators necessary for the required
>> expression
>> is used, or completely in extended format" -part. " 1970-01-01T01:00:00"
>> is
>> legal extended format but illegal basic format, and "+0100" is legal basic
>> format but illegal extended format, and mixing the 2 isn't legal.
>>
>
> Thanks for the reference. I've removed the mention of DateTime::ISO8601
> from the RFC to make sure that the RFC text doesn't make any incorrect
> statements. 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.
>
> Regards,
> Nikita
>
>
>> On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker 
>> wrote:
>>
>> > 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.  Even Notepad properly
>> > handles LF fine for some years now.  It's not really bad, if it can be
>> > explicitely specified.  However, deprecating 't' mode would pave the way
>> > to sometime change shell_exec() to no longer use 't' mode, what is a
>> > footgun when dealing with binary data.  So when using the backtick
>> > operator on Windows, you always need to keep that in mind.  From my
>> > experience, 't' mode causes more harm than good.
>> >
>> > And if there is really the need for LF conversion, that still can be
>> > done with an explicit filter.
>> >
>> > --
>> > Christoph M. Becker
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>> >
>> >
>>
>

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

[Nikita Popov]

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 DateTime formats always refer to
> a specific format, not a set of multiple possible ones, there doesn't seem
> to be anything actionable here.
>
> - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601.
> quoting ISO8601:2004 section 4.3.3:
>
> > For reduced accuracy, decimal or expanded representations of date and
> time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3
> (ordinal dates) or 4.1.4 (week dates) followed immediately by the time
> designator [T] may be combined with any of the representations in 4.2.2.2
> through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local time and
> the difference from UTC) provided that (...skipped stuff...) d) the
> expression shall either be completely in basic format, in which case the
> minimum number of separators necessary for the required expression is used,
> or completely in extended format, in which case additional separators shall
> be used in accordance with 4.1 and 4.2.
>
> DateTime::ISO8601 does exactly what part "d" says isn't legal,
> 1970-01-01T01:00:00 is extended format, and +0100 is basic format, breaking
> the "the expression shall either be completely in basic format, in which
> case the minimum number of separators necessary for the required expression
> is used, or completely in extended format" -part. " 1970-01-01T01:00:00" is
> legal extended format but illegal basic format, and "+0100" is legal basic
> format but illegal extended format, and mixing the 2 isn't legal.
>

Thanks for the reference. I've removed the mention of DateTime::ISO8601
from the RFC to make sure that the RFC text doesn't make any incorrect
statements. 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.

Regards,
Nikita


> On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker 
> wrote:
>
> > 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.  Even Notepad properly
> > handles LF fine for some years now.  It's not really bad, if it can be
> > explicitely specified.  However, deprecating 't' mode would pave the way
> > to sometime change shell_exec() to no longer use 't' mode, what is a
> > footgun when dealing with binary data.  So when using the backtick
> > operator on Windows, you always need to keep that in mind.  From my
> > experience, 't' mode causes more harm than good.
> >
> > And if there is really the need for LF conversion, that still can be
> > done with an explicit filter.
> >
> > --
> > Christoph M. Becker
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

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

[Nikita Popov]

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 targeted at PHP 8.0,
> but was delayed to PHP 8.1 to reduce the amount of changes necessary for
> PHP 8.0 compatibility.
>
> As usual, each deprecation will be voted in isolation.
>
> As we're still early in the release cycle, it's still possible to add
> additional deprecation candidates, given reasoning for the deprecation, as
> well as available alternatives.
>
> Of course, if there are compelling technical reasons why something should
> not be deprecated, we can move things into the "Removed from this proposal"
> section, in which case it will serve as documentation why some
> functionality should not deprecated.
>

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(), get_parent_class() and
get_called_class() without argument" which are mostly stylistic in nature,
and "strftime() and gmtstrftime()", where the non-portability issues are
possibly not so bad that a disruption of existing users is worthwhile.

Regards,
Nikita

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

[Hans Henrik Bergan]

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 multiple possible ones, there doesn't seem
to be anything actionable here.

- this is wrong, DateTime::ISO8601 *is* illegal in ISO8601.
quoting ISO8601:2004 section 4.3.3:

> For reduced accuracy, decimal or expanded representations of date and
time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3
(ordinal dates) or 4.1.4 (week dates) followed immediately by the time
designator [T] may be combined with any of the representations in 4.2.2.2
through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local time and
the difference from UTC) provided that (...skipped stuff...) d) the
expression shall either be completely in basic format, in which case the
minimum number of separators necessary for the required expression is used,
or completely in extended format, in which case additional separators shall
be used in accordance with 4.1 and 4.2.

DateTime::ISO8601 does exactly what part "d" says isn't legal,
1970-01-01T01:00:00 is extended format, and +0100 is basic format, breaking
the "the expression shall either be completely in basic format, in which
case the minimum number of separators necessary for the required expression
is used, or completely in extended format" -part. " 1970-01-01T01:00:00" is
legal extended format but illegal basic format, and "+0100" is legal basic
format but illegal extended format, and mixing the 2 isn't legal.




On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker  wrote:

> 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.  Even Notepad properly
> handles LF fine for some years now.  It's not really bad, if it can be
> explicitely specified.  However, deprecating 't' mode would pave the way
> to sometime change shell_exec() to no longer use 't' mode, what is a
> footgun when dealing with binary data.  So when using the backtick
> operator on Windows, you always need to keep that in mind.  From my
> experience, 't' mode causes more harm than good.
>
> And if there is really the need for LF conversion, that still can be
> done with an explicit filter.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] is_literal

[Rowan Tommins]

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 complex cases of this, e.g. 
https://3v4l.org/GFCQC/rfc#focus=rfc.literals


$literal = 'p';
$ord = ord('o');
$chr = chr($ord+1); // the whole of chr(ord('o')+1) is optimized to a 
literal 'p'

var_dump($chr, is_literal($chr)); // 'p', true


There's a lot of potential for optimizations to leak there, but it's 
*probably* safe, as long as the optimizations all rely on compile-time 
information, and therefore can't be controlled by the user.  Are there 
any run-time optimizations that could also be leaked, e.g. JIT?


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Christoph M. Becker]

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.  Even Notepad properly
handles LF fine for some years now.  It's not really bad, if it can be
explicitely specified.  However, deprecating 't' mode would pave the way
to sometime change shell_exec() to no longer use 't' mode, what is a
footgun when dealing with binary data.  So when using the backtick
operator on Windows, you always need to keep that in mind.  From my
experience, 't' mode causes more harm than good.

And if there is really the need for LF conversion, that still can be
done with an explicit filter.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] is_literal

[Joe Watkins]

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, Claude Pache  wrote:

>
>
> 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 literal
> string - it is not marking an unsafe string as safe.
>
> It's just that existing implementation details - RETURN_CHAR using
> interned strings, and literal constant strings being interned by the
> compiler - lead to a literal string being "re-used".
>
> This is just a natural consequence of literal strings retaining their
> literalness in the way we want them too, nothing dangerous is going on.
>
>
> Hi,
>
> I disagree that it is not dangerous. At the very least, it makes
> `is_literal()` unpredictable, therefore unreliable, which is bad. The
> following git is more illustrative of the issue:
>
> https://3v4l.org/SNJDJ/rfc#focus=rfc.literals
>
> The fact that a given string happens to be written literally somewhere
> else in the program doesn’t mean that it is written literally in that
> context. Taking the example from the RFC:
>
> $qb->select('u')
>->from('User', 'u')
>->where('u.id = ' . $_GET['id']); // INSECURE
>
> I want that the `$qb->where()` method is able to reliably detect that the
> string provided is not literal, even when it happens by chance that the
> exact same string appears literally somewhere else in my code.
>
> —Claude
>
>
>

Re: [PHP-DEV] [RFC] is_literal

[Claude Pache]

> 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 literal 
> string - it is not marking an unsafe string as safe.
> 
> It's just that existing implementation details - RETURN_CHAR using interned 
> strings, and literal constant strings being interned by the compiler - lead 
> to a literal string being "re-used".
> 
> This is just a natural consequence of literal strings retaining their 
> literalness in the way we want them too, nothing dangerous is going on.

Hi,

I disagree that it is not dangerous. At the very least, it makes `is_literal()` 
unpredictable, therefore unreliable, which is bad. The following git is more 
illustrative of the issue:

https://3v4l.org/SNJDJ/rfc#focus=rfc.literals 


The fact that a given string happens to be written literally somewhere else in 
the program doesn’t mean that it is written literally in that context. Taking 
the example from the RFC:

$qb->select('u')
   ->from('User', 'u')
   ->where('u.id = ' . $_GET['id']); // INSECURE
I want that the `$qb->where()` method is able to reliably detect that the 
string provided is not literal, even when it happens by chance that the exact 
same string appears literally somewhere else in my code.

—Claude

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

[Nikita Popov]

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 documentation [1], defining resource constants is supposed to
> “cause unpredictable behavio[u]r” and is “not recommended”. Is this correct
> or just FUD?
>

Well, at least I'm not aware of any "unpredictable behavior" it could
cause. I wouldn't recommend it either -- but that's more because I would
recommend against most uses of define(), not so much resources in
particular.

Regards,
Nikita

Re: [PHP-DEV] [RFC] is_literal

[Joe Watkins]

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 using interned
strings, and literal constant strings being interned by the compiler - lead
to a literal string being "re-used".

This is just a natural consequence of literal strings retaining their
literalness in the way we want them too, nothing dangerous is going on.

Cheers
Joe


On Tue, 15 Jun 2021 at 00:32, Claude Pache  wrote:

>
>
> Le 12 juin 2021 à 19:00, Craig Francis  a
> écrit :
>
> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
>
> Hi,
>
> I’ve found an interesting bug in the implementation:
>
> https://3v4l.org/JfSHX/rfc#rfc.literals
>
> —Claude
>
>
>

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

[Dmitry Stogov]

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

> Hi Dmitry,
>
> Thanks for voicing your concerns.
> I have started writing implementation and it is definitely challenging for
> me, because I am not that experienced with PHP internals yet.
> https://github.com/php/php-src/pull/7131
>
> Almost every implementation requires some amount of work. I would like to
> ask you for more details on why you think this particular change is
> infeasible. Do you see any problems that the implementation of this
> deprecation message would cause? Would it be better to wait for PHP 9.0 and
> remove it without deprecation?
> As I see it, we already have an error for other scalar types. For false,
> we will just need to throw a deprecation notice in the same places. It
> doesn't require a major rewrite of PHP engine from what I can tell.
>
> Regards,
> Kamil
>

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

[Maxime Veber]

> > 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
> “cause unpredictable behavio[u]r” and is “not recommended”. Is this correct
> or just FUD?
>
> [1]: https://www.php.net/manual/en/function.define.php <
> https://www.php.net/manual/en/function.define.php>
>
It also states that it is used for STDIN, STDOU and STDERR, which will be
objects in the future but will still need to be defined for BC.

Regards,
Maxime

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

[Claude Pache]

> 
> 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 “cause 
unpredictable behavio[u]r” and is “not recommended”. Is this correct or just 
FUD?

[1]: https://www.php.net/manual/en/function.define.php 


—Claude