2023年6月24日(土) 22:56 Nikita Popov :
> On Thu, Jun 22, 2023, at 12:14, Máté Kocsis wrote:
> > Hi Everyone,
> >
> > As previously announced on the list, we have just started the vote about
> > the annual PHP deprecation RFC.
> >
> > Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
> >
Hi Sam!
> Hello php internals team,
> I would like to put forward an RFC for a new feature. I am a long time user,
> but have never participated as yet to the RFC.
Sorry for the late reply.
Thanks for your suggestion! If you'd like RFC karma, we'll need to
know your username on the wiki.
Hey Máté,
Only voted "NO" for `ReflectionProperty#setValue()`, mostly because any
kind of pre-existing subtype will be kinda broken, but it isn't a major
issue.
It's fine if libraries drop support for PHP 8.2 before PHP 9.0 is out.
Marco Pivetta
https://mastodon.social/@ocramius
On Wed, 31 May 2023 at 13:08, G. P. B. wrote:
> Hello internals,
>
> I would like to start the discussion about deprecating various remains
> from the now removed string code evaluated assertions functionality of
> assert().
>
> The RFC is located on the wiki at the following address:
>
On Tue, Jun 20, 2023 at 9:46 PM Levi Morrison wrote:
>
> On Tue, Jun 20, 2023 at 6:29 AM David Gebler wrote:
> >
> > On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote:
> >
> > > > I like the idea of this RFC - in fact it's one which has been near top
> > > > of
> > > > my wishlist for PHP
On Wed, 31 May 2023 at 23:20, Claude Pache wrote:
> Although your RFC says that the `zend.assertions` ini setting has
> superseded `assert.active` for a while, the “official” php.ini file still
> advises to modify the value of `assert.active` rather than the one of
> `zend.assertion` in order to
On Mon, Jun 26, 2023, at 6:45 AM, Go Kudo wrote:
> 2023年6月24日(土) 22:56 Nikita Popov :
>
>> On Thu, Jun 22, 2023, at 12:14, Máté Kocsis wrote:
>> > Hi Everyone,
>> >
>> > As previously announced on the list, we have just started the vote about
>> > the annual PHP deprecation RFC.
>> >
>> > Link to
Hi Everyone,
As previously announced on the list, I have just started the vote about the
"Deprecate functions with overloaded signatures".
Link to the RFC:
https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
Link to the discussion thread: https://externals.io/message/120146
On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> > On Jun 26, 2023, at 08:36, Máté Kocsis wrote:
> >
> > Hi Everyone,
> >
> > As previously announced on the list, I have just started the vote about the
> > "Deprecate functions with overloaded signatures".
> >
> > Link to the RFC:
> >
> On Jun 26, 2023, at 08:36, Máté Kocsis wrote:
>
> Hi Everyone,
>
> As previously announced on the list, I have just started the vote about the
> "Deprecate functions with overloaded signatures".
>
> Link to the RFC:
> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
>
> On Jun 20, 2023, at 06:06, Rowan Tommins wrote:
>
> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo wrote:
>
>> Introduce a new function (currently named populate_post_data()) to
>> read the input stream and populate the $_POST and $_FILES
>> superglobals.
>>
>
>
> My initial instinct was to
On Mon, June 26, 2023, at 14:43 Nikita Popov wrote:
> On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> >
> > I voted “no” on `array_keys()` because I do not see these as two different
> > function signatures. To me, the single signature should look like this:
> >
> > function
With "Interface Default Methods" potentially becoming a thing, it begs the
question for the need to have Interface Properties, at least `private` ones and
`private static` ones.
How can we have default getters and default setters in an interface if there
are no private interface properties to
On Tue, 17 Jan 2023 at 14:28, G. P. B. wrote:
> Hello Internals,
>
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by making $v++
> behave
On 26.06.2023 20:22, Ben Ramsey wrote:
I voted “no” on `IntlCalendar::set()` because it seems to me that `setDate()`
and `setDateTime()` could share the same signature if `$hour`, `$minute`, and
`$second` all default to zero, like this:
public function setDate(int $year, int $month, int
15 matches
Mail list logo
