Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

[Derick Rethans]

On Fri, 19 Jul 2024, Gina P. Banyard wrote:

> Hello internals,
> 
> I have opened the vote for the mega deprecation RFC:
> https://wiki.php.net/rfc/deprecations_php_8_4
> 
> Reminder, each vote must be submitted individually.

I have voted no for a few, as they had no impact assesment at all:

- Deprecate returning non-string values from a user output handler
- Deprecate lcg_value()
- Deprecate md5(), sha1(), md5_file(), and sha1_file() (just says "large 
  impact")
- Deprecate SOAP_FUNCTIONS_ALL constant and passing it to 
  SoapServer::addFunction()

And no on a few others:

- Deprecate using a single underscore ''_'' as a class name (it breaks 
  some of my ... old slides — but I also don't really the problem with 
  this.
- Remove the E_STRICT Error Level and Deprecate the E_STRICT constant?  
  (Because I added it :-) )

cheers,
Derick

Re: [PHP-DEV] Website php.net updates and coordination

[Derick Rethans]

(Follow ups to this should probably go to php-webmas...@lists.php.net 
only, and no longer internals@)

On Thu, 11 Jul 2024, Jim Winstead wrote:

> On Thu, Jul 11, 2024, at 6:54 AM, Derick Rethans wrote:
> >
> > It is the RMs: https://github.com/orgs/php/teams/release-managers 
> > and web-team: https://github.com/orgs/php/teams/web-team
> >
> > Each has 13 members, but there are some overlaps.
> 
> These aren't public. The only public info appears to be the members of 
> the PHP organization on GitHub, and I think something needs to be done 
> to make the teams and roles (owner, moderator, etc) public 
> information. This could probably be scripted and automated because it 
> looks like it's not just a matter of flipping a switch somewhere on 
> the GitHub side.

I thought they were public.

I also had a look, and there is no switch anywhere.

Going forward, Roman and I have been speaking about getting a more 
formal group together here (php-webmaster@) that makes decisions here, 
as ad-hoc commits to PHP's website are as much of an issue than ad-hoc 
commits to its source code.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Website Analytics (Was: Re: [PHP-DEV] Website php.net updates and coordination)

[Derick Rethans]

On Wed, 10 Jul 2024, Roman Pronskiy wrote:

> 2. Analytics
> It is hard to make any decisions without having a reliable source of
> stats and data. With more than 17,000 pages, updating all of them is
> impractical. Analytics, among other things, will help us prioritize
> updates based on page importance. Using a self-hosted Matomo instance
> seems a viable option for this. Derick Rethans will follow up with
> more details.

I have looked at a few different solutions, and the most reasonsable 
seems to self-host a Mamato (formerly Piwik) instance. This means no 
analytics data will get send to third parties.

I have set up this instance already (https://analytics.php.net, SSL 
certificate not active yet) and also briefly experimented with it.

In order to collect data, we will need to add the following snippet to 
php-web:

https://github.com/php/web-php/commit/aef3309d2508b1e1ca0db5c50c829dfdfa7ee24f

By default, nobody (besides me and Roman) would be able to view the 
analytics either, but I am open to opening this up for other interested 
members of the PHP development team.

I will leave it to Roman to make the case of what sort of information he 
would like to obtain, and why.

Opinions?

cheers,
Derick

Re: [PHP-DEV] Website php.net updates and coordination

[Derick Rethans]

On Wed, 10 Jul 2024, Roman Pronskiy wrote:

> 3. Deployment Process
> Recently, there was an incident with a code block pushed to the
> website accidentally: https://github.com/php/web-php/pull/1021. It was
> promptly reverted, but the case highlighted a potential security risk:

It wasn't an *accident* that I pushed it. Only people with commit access 
to php-web can push things, and that isn't a large list of people.

It is the RMs: https://github.com/orgs/php/teams/release-managers
and web-team: https://github.com/orgs/php/teams/web-team

Each has 13 members, but there are some overlaps.

The deploy scripts are all part of php-systems, of which only the 
repository owners can commit to, and web-master, which only the above 
mentioned web-team can commit to.

> unauthorized modifications could go unnoticed, potentially affecting
> all visitors of the php.net website worldwide. In theory, malicious
> code could be added to the server directly if access is compromised,
> with high chances of being unnoticed.

All commits to web-php and web-master are emailed to a mailinglist: 
https://news-web.php.net/php.webmaster which I actively monitor.

We can probably improve on this this, but this is all pretty tight, 
moreso than committing random things to the PHP source repository.

cheers,
Derick

Re: [PHP-DEV] Negatively Voted Notes

[Derick Rethans]

On Wed, 10 Jul 2024, Tim Düsterhus wrote:

> On 7/10/24 16:18, Derick Rethans wrote:
> > Comments?
> 
> For now I'm only asking to give me the time to go through the 
> ext/random stuff myself before the automated deletion is performed 
> (i.e. defer this until after feature freeze at least).

That will take no time, as there are no comments (at all) for the random 
engine yet!

Only the older functional API has 7 with a score less than -5:

| function.array-rand  | 2021-12-03 15:06:19 |  126659 | -7 
|
| function.rand| 2020-10-05 11:07:56 |  125416 | -9 
|
| function.openssl-random-pseudo-bytes | 2012-05-06 00:17:49 |  108550 | -9 
|
| function.openssl-random-pseudo-bytes | 2018-02-24 16:08:49 |  122436 | -9 
|
| function.random-bytes| 2018-05-25 00:06:34 |  122766 |-15 
|
| function.rand| 2010-03-05 18:41:06 |   96583 |-16 
|
| function.openssl-random-pseudo-bytes | 2017-10-31 17:18:05 |  121817 |-19 
|

(And they are indeed delete worthy).

cheers,
Derick

Re: [PHP-DEV] Negatively Voted Notes

[Derick Rethans]

On Wed, 10 Jul 2024, Gina P. Banyard wrote:

> On Wednesday, 10 July 2024 at 15:18, Derick Rethans  wrote:
> 
> > We discussed this during one of our foundation meetings, and we propose:
> > 
> > - to delete all notes with a rating less than -5 that are older than a
> > year.
> > - come up with a plan to crowd source going through the other thousands
> > of notes to see if they need to be deleted or integrated into the
> > actual text. Each documentation page now has a link to the XML source
> > (such as https://github.com/php/doc-en/blob/master/language/attributes.xml)
> > 
> > Comments?
> 
> One question, should this possibly become a monthly cron job that 
> checks for the user notes and removes those that fall below the above 
> criterias?

I was indeed intending for this to become a recurring job. There is 
already a script that (should) emails weekly the top-commented pages, 
but it currently fails email delivery.

I have now fixed that 
(https://github.com/php/web-master/commit/f2add6e1ff11332c56177ca295d4fbf2f4ccbd49),
 
and the result is at https://news-web.php.net/php.notes/221419

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Negatively Voted Notes

[Derick Rethans]

On 10 July 2024 18:47:07 BST, fennic log  wrote:
>On Wed, 10 Jul 2024 at 15:18, Derick Rethans  wrote:
>
>> Hi!
>>
>> There are currently nearly 2 notes in the documentation, with many
>> having a very high negative rating.
>>
>> For example, there are:
>>
>> 1131 notes older than a year, with a rating less than -10
>> 2339 notes older than a year, with a rating less than -5
>> 5761 notes older than a year, with a rating less than -1
>>
>> The worst offender is:
>>
>> https://www.php.net/manual/en/features.cookies.php#128286 with -159 (not
>> sure why the website says -153)
>> https://www.php.net/manual/en/language.attributes.overview.php#126887
>> with -104
>>
>> We discussed this during one of our foundation meetings, and we propose:
>>
>> - to delete all notes with a rating less than -5 that are older than a
>>   year.
>> - come up with a plan to crowd source going through the other thousands
>>   of notes to see if they need to be deleted or integrated into the
>>   actual text. Each documentation page now has a link to the XML source
>>   (such as
>> https://github.com/php/doc-en/blob/master/language/attributes.xml)
>>
>> Comments?
>
>This is something im both For and Against.
>
>On the *for* side, alot of these notes are negative rated for a reason, bad
>code, bad advice, incorrect usage, etc etc
>
>But on the *against* said is removing information, no matter how bad the
>code is or misunderstood, in my eyes no information should be removed. Let
>users see others' mistakes, so they dont repeat them.
>This is what the rating system is for. The only stuff that I wouldn't be
>against is clearly
>advertising/promotional/spam posts.
>
>If we had a thread system for these comments, so others can reply, they can
>point out mistakes/bad code/incorrect usage and those reading can learn
>what and what not to do.

Notes where never meant to be helpful to other developers. They were hints to 
the editors to include missing information, to add clarification, and sometimes 
to add new examples *into* the documentation, and then delete the note. This is 
less needed now as each page has a direct link to "report a bug" or the XML 
source. 

The rating systems was another hint to the editors of the manual to see how 
wrong of helpful a hint for them was. 

Walls of code with "special functions", or questions, or incorrect comments 
were always deleted without prejudice. 

Help threads and discussions belong on the php-general list of somewhere else. 

cheers 
Derick 

Re: [PHP-DEV] [Discussion] Add date_test_set_now() function

[Derick Rethans]

On Mon, 1 Jul 2024, Go Kudo wrote:

> So, how about adding a `date_set_test_now(\DateInterval 
> $shiftInterval)` function to ext-date?
> 
> This function would treat the current time as shifted by the passed 
> DateInterval. Since it's implemented on the ext-date side, there's no 
> need for dirty hacks using usleep.

It's not that easy, as maney calculations are done in "timelib".

Especially for shifting times with relative times, the parser will need 
to understand that too I suppose.

I am not keen on adding this global override to this library.

cheers,
Derick

Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function

[Derick Rethans]

On Mon, 1 Jul 2024, Lanre wrote:

> On Mon, Jul 1, 2024 at 2:21 PM Jorg Sowa  wrote:
> 
> > > You don’t make any effort to help or provide constructive criticism; you
> > just love to (incorrectly) tell everyone what they're doing wrong and how
> > they should be doing it, without adding anything constructive to the
> > conversation.
> >
> > Please limit to the arguments on the topic, not a person.
> >
> > The argument "Relying on the global mutable state is a bug" is completely
> > valid and in most of the cases is the signal of bad design. And it has been
> > already addressed in some of the functions, look at
> > https://wiki.php.net/rfc/deprecations_php_8_3 for deprecations on rand
> > functions. However, it's not so trivial to fix everything introducing
> > compatibility-breaking changes. So it shouldn't be advised to add more of
> > such functions.
> >
> 
> It still doesn't make sense. Even if we removed all the functions from my
> list, the entire engine remains filled with global state. Internal
> zend_class_entry instances, arginfo macros, the interned string table,
> executor/compiler/scanner/each-extension globals, and so on—all contribute
> to global state -- or bugs according to you and Larry, unless your stupid
> argument applies only to languages under your control.

You really need to tone this langauge down. It's not the first time that 
this has been requested of you. Ad-hominems are not welcome here.

I will point out the mailing list rules once more (only):
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md

cheers,
Derick

[PHP-DEV] Negatively Voted Notes

[Derick Rethans]

Hi!

There are currently nearly 2 notes in the documentation, with many 
having a very high negative rating.

For example, there are:

1131 notes older than a year, with a rating less than -10
2339 notes older than a year, with a rating less than -5
5761 notes older than a year, with a rating less than -1

The worst offender is:

https://www.php.net/manual/en/features.cookies.php#128286 with -159 (not sure 
why the website says -153)
https://www.php.net/manual/en/language.attributes.overview.php#126887 with -104 

We discussed this during one of our foundation meetings, and we propose:

- to delete all notes with a rating less than -5 that are older than a 
  year.
- come up with a plan to crowd source going through the other thousands 
  of notes to see if they need to be deleted or integrated into the 
  actual text. Each documentation page now has a link to the XML source
  (such as https://github.com/php/doc-en/blob/master/language/attributes.xml)

Comments?

cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Re: VCS Account Request: youkidearitai

[Derick Rethans]

On Wed, 10 Jul 2024, youkidearitai wrote:

> 2024年7月1日(月) 21:43 youkidearitai :
> >
> > 2024年7月1日(月) 21:19 Ilija Tovilo :
> > >
> > > Sorry for the delay. I granted you access to the php-src 
> > > repository. Please familiarize yourself with our merging process 
> > > [1]. Note that I unfortunately cannot (and wouldn't know how to) 
> > > create main.php.net accounts. They are pretty much unused nowadays 
> > > except for the wiki. I can ask Derick to create one once he's back 
> > > from vacation.
> > >
> > > Feel free to ping me if you have any questions. Thank you for 
> > > contributing to PHP!
> >
> > Thank you very much for granted to the php-src repository. I 
> > understand about main.php.net. I'll contribute more to PHP!
> 
> Hi, Ilija, Derick!
> 
> What should I do about main.php.net?

I wasn't aware that you still needed that now you've got php-src commit 
access?

cheers,
Derick

Re: [PHP-DEV] [RFC] Property Hook improvements

[Derick Rethans]

On Mon, 1 Jul 2024, Larry Garfield wrote:

> Hi folks.  As Ilija's been polishing off hooks to get the PR merged, 
> we've run into two small revisions that should make life better for 
> all involved.  One is a performance improvement that requires a very 
> slight error handling behavior change, and the other is enabling 
> readonly in selected (but probably all of the relevant) circumstances.
> 
> I'd say we expect these to be uncontroversial, but this is PHP. :-)  
> So I will instead just note that it's a short RFC and open the 
> discussion accordingly.
> 
> https://wiki.php.net/rfc/hook_improvements

1. Remove the proactive guard against recursive backing value access

"which would eventually trigger a stack overflow"

Would it though? PHP 8.4 has an actual protection against this now, 
instead of getting the white-screen-of-death.

Not that it matters much, but it's probably good to be precise in the 
language.

cheers,
Derick

Re: [PHP-DEV] [RFC] Property Hook improvements

[Derick Rethans]

On Wed, 3 Jul 2024, Claude Pache wrote:

> > Le 1 juil. 2024 à 19:02, Larry Garfield  a 
> > écrit :
> > 
> > Hi folks.  As Ilija's been polishing off hooks to get the PR merged, 
> > we've run into two small revisions that should make life better for 
> > all involved.  One is a performance improvement that requires a very 
> > slight error handling behavior change, and the other is enabling 
> > readonly in selected (but probably all of the relevant) 
> > circumstances.
> > 
> > I'd say we expect these to be uncontroversial, but this is PHP. :-)  
> > So I will instead just note that it's a short RFC and open the 
> > discussion accordingly.
> > 
> > https://wiki.php.net/rfc/hook_improvements
> 
> 1. Removing the guard against recursion is sensible to me, as the sort 
> of bug it is supposed to prevent is not specific to property 
> accessors. IMO, a better solution to the issue is to implement a 
> global upper limit on the call stack size.

That is already done in PHP 8.4, if you end up using too much stack, PHP 
will now bail out graciously: 
https://github.com/php/php-src/blob/master/Zend/zend_call_stack.c

> Currently, I am able to generate a call stack of more than 10 millions 
> items before an OOM error occurs; PHP should have thrown a stack 
> overflow error long before that.

Why? Most actual function calls are not done on the stack any more. So 
it is now perfectly okay to have that many nested calls. If you want it 
to bail out earlier (during testing), then Xdebug will help you.

cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

[Derick Rethans]

On Tue, 9 Jul 2024, Tim Düsterhus wrote:

> On 7/8/24 06:29, Saki Takamachi wrote:
>
> > I don't think a satisfactory specification will be decided on this 
> > before the feature freeze, so I will not rush into discussing this 
> > RFC for now. Of course, no voting will take place until the 
> > specifications are decided. If we were to discuss this change again, 
> > it would be in versions beyond 8.4.
> 
> I agree with Juliette that as long as passing a non-integer float to 
> an int parameter is only a deprecation warning, widening the signature 
> to `string|int` is too much of a breaking change.

I agree too, and don't think we should change this in PHP 8.x.

and probably would also question:

"bcfloor() and bcceil() are excluded because there is no point in 
allowing int type arguments due to the characteristics of their 
functions. "

Although that is right, having these *also* accept ints would at least 
be consistent.

cheers,
Derick

Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath

[Derick Rethans]

On Wed, 10 Jul 2024, Derick Rethans wrote:

> On Mon, 1 Jul 2024, Saki Takamachi wrote:
> 
> The example has:
> 
>   [$perMouth, $slicesLeft] = $slicesOfPizza->divmod($mouthsToFeed);
>
>   // $perMouth->value is '2'
>   // $slicesLeft->value is '2'
> 
> Shouldn't that be (without the ->value) ?

I can answer this myself now :-) No, it shouldn't be, as $perMouth is a 
Number object.

cheers,
Derick

Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath

[Derick Rethans]

On Mon, 1 Jul 2024, Saki Takamachi wrote:

> Hi,
> 
> >> Just a suggestion: what about making the returned array an associative
> >> array ? Like so:
> >> ```
> >> array(
> >>  'quotient' => 61,
> >>  'remainder' => 1,
> >> );
> >> ```
> >> This would remove the need for devs to remember the order of the return
> >> values and would make the return value self-documenting.
> > 
> > An associative array would combine the worst of an array (no IDE 
> > autocompletion, no strong typing, increased memory usage) with the worst of 
> > an object (no easy way to extract the values into local variables with 
> > array destructuring).
> > 
> > The example in the RFC doesn't show it, but the following makes the 
> > proposed API really convenient to use:
> > 
> >$slicesOfPizza = new BcMath\Number(8);
> >$mouthsToFeed = new BcMath\Number(3);
> >[$perMouth, $slicesLeft] = $slicesOfPizza->divmod($mouthsToFeed);
> > 
> > Note how the order of values matches the words in the method name. First 
> > the result of 'div', then the result of 'mod’.
> 
> 
> Thanks, I have added this example to the RFC (Please let me know if you have 
> any problems).

The example has:

[$perMouth, $slicesLeft] = $slicesOfPizza->divmod($mouthsToFeed);
 
// $perMouth->value is '2'
// $slicesLeft->value is '2'

Shouldn't that be (without the ->value) ?

[$perMouth, $slicesLeft] = $slicesOfPizza->divmod($mouthsToFeed);
 
// $perMouth is '2'
// $slicesLeft is '2'

cheers,
Derick

Re: [PHP-DEV] [RFC] Static class

[Derick Rethans]

On Tue, 25 Jun 2024, Chuck Adams wrote:

> > On Jun 25, 2024, at 9:17 AM, Derick Rethans  wrote:
> >
> > Having read this thread, and the previous one from half a year ago, 
> > I will do so too. In short, we shouldn't be encouraging static 
> > classes as a bag of static functions, that ought to be just 
> > namespaced functions.
> 
> Which brings us back to the age-old problem that functions can’t be 
> autoloaded. Me, I want first-class modules, but until we have those, I 
> have to settle for classes in the meantime. Scala/Kotlin-like 
> “companion objects” might be a good all-round substitute though.

There has been some work done on function autoloading too:
https://wiki.php.net/rfc/core-autoloading

cheers,
Derick

Re: [PHP-DEV] [RFC] Static class

[Derick Rethans]

On Wed, 26 Jun 2024, Lanre wrote:

> That isn't a top post, look again.

It was.

If people point out you're doing something against this list's
guidelines, don't reply with "it wasn't" in a snarky way.

cheers,
Derick

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

[Derick Rethans]

On 26 June 2024 20:59:00 BST, Richard Miles  wrote:
>Howdy people, 
>
>The pattern-matching RFC inspired me to write this. I have not done any work 
>for this yet; just looking for initial feedback. I think we should have typed 
>arrays in PHP. I propose adding the class SplTypeDefinedArray.

We've done some initial work related to this as part of PHP Foundation work:


A summary on the state of this, and actual genetics will be available soon too. 

cheers
Derick 

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

[Derick Rethans]

Please, no top posting.

On Tue, 25 Jun 2024, Marco Pivetta wrote:

> I agree with most of these deprecations, except:
> 
>  * `uniqid()`, in my case (XKCD 1172) is largely used for quickly
> generating a semi-random string for test purposes: a suitable replacement
> PRNG implementation would be welcome. Even refactoring with tools like
> Rector will lead to quite messy code, or added dependencies. IMO fine to
> get rid of **this specific implementation**, if a safe function is
> provided, such as `random_ascii_string()` or such (dunno, just a hint)

>  * `md5()`, `sha1()` - OK-ish with moving to `hash('', ...)`, but
> while these are insecure for most use-cases, they are part of the domain of
> many tools, including GIT itself. I can Rector my way out of it, just not
> sure these should be hidden into `hash(...)`

I agree on both points.

These functions are indeed often used. The documentation for uniqid has 
some nice big warnings too. It can be used in situations, where it is 
OK.

Replacing the algorithm underneath uniqid can (and perhaps should) be 
looked at.

For the md5 and sha1 functions. Although these algorithms are not useful 
for "verifying the authenticity of a a payload", that doesn't mean they 
can't be used outside of that use case. 

I understand the reasons why you want to "nudge" people to no longer use 
these "unsafe" functions, but IMO, in this case, it's not worth the 
BC issues.

cheers,
Derick

Re: [PHP-DEV] [Early Feedback] Pattern matching

[Derick Rethans]

On Mon, 24 Jun 2024, Larry Garfield wrote:

> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
> 
> * The placement of `is` on `match()` is still an open question.

"The latter is more explicit, and would allow individual arms to be 
pattern matched or not depending on the presence of is."

Which would make it probably more useful, so I would be in favour of 
having each arm have the "is".

> * No one has really weighed in on nested patterns for captured 
> variables.  Any thoughts there?

In your example, you have:

if ($foo is Foo{a: @($someA), $b is Point(x: 5, y: @($someY)) }) {

And my brain can't parse that. I would have *no* idea what that means at 
first sight.

In addition to just normal captured, variables:

"For object patterns (only), if the variable name to extract to is the 
same as the name of the property, then the property name may be 
omitted."

This is one I don't like. It adds another syntax, and IMO also makes 
something less obvious what is happening. Too much magic™.

So please:

if ($p is Point {z: $z, x: 3, y: $y} ) {

And not:

if ($p is Point {$z, x: 3, $y} ) {


cheers,
Derick

Re: [PHP-DEV] [RFC] Static class

[Derick Rethans]

On Sun, 23 Jun 2024, Larry Garfield wrote:

> On Sun, Jun 23, 2024, at 6:10 PM, Bilge wrote:
> > Hi Internals!
> >
> > I am pleased to present my first RFC: Static class 
> > .
> >
> > This work is based on the previous discussion thread on this list of the 
> > same name, and hopefully captured all the relevant details, 
> > notwithstanding anything unanticipated that may present itself during 
> > the implementation. Let me know if you feel anything important has been 
> > missed. I am aware it omits to mention specifics about messages so 
> > emitted when runtime or compile-time errors occur, but I anticipate this 
> > can be hashed out in the PR, unless consensus indicates otherwise.
> >
> > I am aware this idea is not supported by everyone, but there seemed to 
> > be enough positive voices for it to be worth a shot. I'd like to get a 
> > better idea of where people might stand when it comes down to a vote, 
> > now there is a formal RFC, so we know whether it's worth completing the 
> > implementation, although any sentiments so proffered are of course not a 
> > commitment to vote any particular way and nobody should feel compelled 
> > to speak to that unless comfortable. Looking forward to feedback!


> 
> For the record, as previously stated, I will be voting No on this RFC.

Having read this thread, and the previous one from half a year ago, I 
will do so too. In short, we shouldn't be encouraging static classes as 
a bag of static functions, that ought to be just namespaced functions.

cheers,
Derick

Re: [PHP-DEV] Revisiting case-sensitivity in PHP

[Derick Rethans]

On Fri, 14 Jun 2024, Lanre wrote:

> Coming from the property hooks/ asymmetric visibility dude, that's pretty
> rich.

Please, ad-hominem (and other) attacks are not welcome on this list. 

Please familiarise yourself with the mailinglist rules 
(https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md).

with kind regards,
Derick

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

[Derick Rethans]

On 10 June 2024 21:17:38 BST, Lanre  wrote:
>You guys are killing PHP. There is a lot of work to be done on the engine
>to modernize it and make it more robust and sturdy. Shit like this just
>adds more complexity to PHP in the name of convenience. I think this is my
>cue to explore other languages for handling requests


Please moderate your language.

Posts like this do nothing except a higher chance for people to ignore you, 
when you've actual points to make, such as credible suggestions as to how to 
make PHP "more rubust and sturdy".

Looking forwards to your RFCs and patches.

cheers
Derick

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

[Derick Rethans]

On Fri, 31 May 2024, Saki Takamachi wrote:

> I would like to start an RFC discussion regarding rounding modes. 
> https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum

I think it would be really helpful to have a description (and examples) 
for each of the rounding modes in the Enum 
(https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum#proposal)
 
— that'd also be great for creating documentation later on.

cheers,
Derick

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

[Derick Rethans]

On Sat, 1 Jun 2024, Gina P. Banyard wrote:

> On Friday, 31 May 2024 at 18:15, Larry Garfield  
> wrote:
> 
> > On Fri, May 31, 2024, at 4:41 PM, Jorg Sowa wrote:
> > 
> > > Hey Saki, I like this change. When I was implementing additional 
> > > rounding modes for the next PHP version I was initially struggling 
> > > with the naming and this change will be helpful.
> > > 
> > > I have only one concern about the names `NegativeInfinity` and 
> > > `PositiveInfinity`. They may be too formal from the user's 
> > > perspective. As we already have functions `ceil` and `floor` it's 
> > > more intuitive for developers to understand the logic of ceiling 
> > > and floor rounding.
> > > 
> > > But if voters will prefer those terms then it makes sense to 
> > > change the constants implemented in PHP 8.4 (and thus not released 
> > > yet) from `PHP_ROUND_(CEILING|FLOOR)` to 
> > > `PHP_ROUND_(POSITIVE_INFINITY|NEGATIVE_INFINITY)` for the sake of 
> > > consistency.
> > 
> > I was confused by those as well. It's not obvious to me what those 
> > even do. Do they mean "away from 0"? If not, then I have no clue 
> > what they are. :-)
> 
> Considering that there are already "Away from 0" and "Towards 0" enum 
> cases, the Towards Positive Infinity/Towards Negative Infinity cases 
> "obviously" don't mean this.
> 
> Towards positive infinity means that for positive numbers you round to 
> the integer part plus 1, and for negative numbers you "just" take the 
> negative integer part. Similarly, for rounding towards negative 
> infinity positive numbers round to "just" the integer part of it, and 
> negative numbers round to the negative integer part minus 1.
> 
> It should also be noted that ceil/floor is very English specific 
> terminology that may not be immediately obvious to non-English 
> speakers, thus my preference for using some variation of towards 
> positive/negative infinity.

But they're well established in existing PHP features.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

[Derick Rethans]

On Thu, 30 May 2024, Alexandru Pătrănescu wrote:

> On Wed, May 29, 2024 at 10:18 PM Larry Garfield 
> wrote:
> 
> > As promised, Ilija and I offer this revised version of asymmetric
> > visibility.
> >
> > https://wiki.php.net/rfc/asymmetric-visibility-v2
> >
> >
> Hey Larry, Ilija,
> 
> I have one concern so far, and it's related to the inheritance section.
> 
> If in a class I define the property as private,
> I know that there is no way for external scope or extending classes scope
> to read or write to the property.
> (of course, ignoring reading/writing using reflection or re-binded closures)
> 
> If an extending class defines the property with a wider visibility,
> protected or public, it will shadow the initial one and not change its
> visibility.

private and protected differ here already, even without async 
visibility:

https://3v4l.org/8Ynog

A protected property does not create a new bag to store data in, which 
does happen for a private property.

> Now, if I define the property as public private(set) with similar 
> intentions, to make sure that there is no way for external scope or 
> extending classes scope to write to the property, while allowing 
> reading from external scope (or extending classes scope).
> 
> But the problem is that an extending class can define the property as 
> public protected(set), and that will easily allow the property that I 
> wanted to make sure it is private for writing to be changed by an 
> extending class to be protected.

public private(set) properties aren't really private, so you don't get 
the shadowing, but you do have a point wrt to the expectation that an 
inherited class can't easily override the private(set) part (with 
protected(set) or public(set)).

Hopefully Ilija or Larry can explain :-)

cheers,
Derick

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Derick Rethans]

On Tue, 28 May 2024, Tim Düsterhus wrote:

> On 5/28/24 16:26, Derick Rethans wrote:
>
> > I have just checked this for Xdebug, and you're definitely right 
> > with that. With the removal of the ZEND_EXIT opcode, it can not now 
> > detect a scope/function exit now.
> 
> Can you clarify why ZEND_EXIT is special for Xdebug when compared to 
> any other function that unconditionally throws or unconditionally 
> calls exit(); by itself, i.e. any other function with a `never` return 
> type?

For each op_array, Xdebug tries to figure out every possible path by 
following jumps. Certain opcodes, such as GENERATOR_RETURN, THROW, 
RETURN, and EXIT [1] are considered as an exit point out of the 
function. A path ends there.

If there is a function call to a function with a 'never' return type, 
then that function will potentially throw, or exit.

But that's not relevant for the analysis, as these userland functions 
will have their own oparrays with their entry and exit points.

I can't through this mechanism know when an *internal* function does 
something similar, as it looks like just a normal function call (unless 
I hard code the check for a call to 'exit').

[1] 
https://github.com/xdebug/xdebug/blob/master/src/coverage/code_coverage.c#L348

> > It also breaks my "do tasks on ZEND_EXIT" with the profiler. It is 
> > used to always write the closing profiling footer to the files. 
> > Without me being able to overload thati opcode, data would not be 
> > complete. I even have two bugs (with tests) for this:
> > 
> > - https://bugs.xdebug.org/68
> > - https://bugs.xdebug.org/631
> 
> Likewise, how is ZEND_EXIT special here? How does it work differently than a
> script that runs to completion without calling exit(); or a script that fails,
> e.g. due to an uncaught exception or due to reaching the memory limit?

I overload EXIT so that I can flush the profile file before the script 
actually fully ends. This is useful for testing through phpt tests. It 
looks like I might be able to use existing function observers for this, 
but I haven't fully made that work yet.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Derick Rethans]

On Tue, 28 May 2024, Gina P. Banyard wrote:

> On Tuesday, 28 May 2024 at 15:26, Derick Rethans  wrote:
> 
> > On Mon, 27 May 2024, Ilija Tovilo wrote:
> > 
> > > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe 
> > > wrote:
> > > 
> > > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard 
> > > > intern...@gpb.moe wrote:
> > > > 
> > > > > I would like to formally propose my idea for exit() as a 
> > > > > function brought up to the list on 2024-02-24 [1] with the 
> > > > > following RFC: https://wiki.php.net/rfc/exit-as-function
> > > > 
> > > > As there haven't been any comments for nearly two weeks, I'm 
> > > > planning on opening the vote for the RFC on Tuesday.
> > 
> > 
> > Right now, I am not going to be in favour of this. Specfically 
> > because the Backward Incompatible Changes don't list some of the 
> > backward breaking changes, and no mitigations are provided. See 
> > below.
> > 
> > I also don't see the benefit from doing this in the first place. 
> > exit/die has always meant "bail straight out", without any function 
> > semantics (from https://www.php.net/exit):
> > 
> > exit — Output a message and terminate the current script
> > 
> > exit is a language construct and it can be called without 
> > parentheses if no status is passed.
> > 
> > It's not that this a particularly new or novel behaviour.
> > 
> > I saw somewhere else in the thread that the exit construct could 
> > already throw a catchable exception. I consider that a bug.
> 
> Considering the whole point of the RFC is to make it a function, I'm 
> not sure why saying the current exit behaviour is not new or novel 
> serves any purpose.

I understand that that is the point, but I don't think it's argued *why* 
that needs to happen.

> Is catching a TypeError a bug? Is catching a ValueError a bug? Is 
> catching any sort of engine Error a bug?

exit throwing any Exception is the bug I was referring to.

> Because this is effectively what you are saying, and if this is the 
> case, we might as well just reverse the "Exceptions in the engine" RFC 
> from 2014 [1] to make all those Errors fatal errors again which bail 
> out immediately. This RFC makes exit() a function such that either it 
> exits normally, or a TypeError is thrown if you feed it nonsense, 
> consistently with all our type juggling semantics.
> 
> Moreover, when exit() was changed to use an Exception internally there 
> were various people in favour of being able to catch it, and have it 
> run finally blocks (like other programming languages do) [2] It should 
> also be noted exit() does not just bail out and do nothing else, any 
> destructors will be run before the exiting, so one can still run 
> userland code after it has been called [3]
> 
> > I have just checked this for Xdebug, and you're definitely right 
> > with that. With the removal of the ZEND_EXIT opcode, it can not now 
> > detect a scope/function exit now.
> > 
> > It also breaks my "do tasks on ZEND_EXIT" with the profiler. It is 
> > used to always write the closing profiling footer to the files. 
> > Without me being able to overload thati opcode, data would not be 
> > complete. I even have two bugs (with tests) for this:
> > 
> > - https://bugs.xdebug.org/68
> > - https://bugs.xdebug.org/631
> > 
> > Xdebug has been overloading ZEND_EXIT for nearly 20 years now.
> 
> AFAIK Opcodes are not part of any backwards compatibility guarantees.

AFAIK it isn't documented otherwise either. Just because it's not 
documented, doesn't mean we should remove long term existing 
functionality.

> You could overwrite the function pointer of exit() at MINIT with a 
> custom implementation.

I can, but overriding functions for this sort of thing is a little bit 
of a hack, and I prefer having an actual API. It is also a runtime 
feature, not a compile time (see below again).

> Alternatively, you could use the zend_is_unwind_exit() engine API to 
> check if the exception that has been thrown is the one that 
> corresponds to an exit call, this would work as of PHP 8.0.

> Finally, the one that makes more work for me, is to add a new observer 
> API that indicates an exit() and hook into that one.

That seems a fairly sensible thing to add. But that only addresses my 
profiler use case, and not the branch/path detection use case.

> > 
> > > This could be re-added by checking for the never return type instead.
> > 
> > 
> > I can't quite see a way on how to do that? The EXIT is re

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Derick Rethans]

On Mon, 27 May 2024, Ilija Tovilo wrote:

> On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard  
> wrote:
> >
> > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard 
> >  wrote:
> >
> > > I would like to formally propose my idea for exit() as a function 
> > > brought up to the list on 2024-02-24 [1] with the following RFC: 
> > > https://wiki.php.net/rfc/exit-as-function
> >
> > As there haven't been any comments for nearly two weeks, I'm 
> > planning on opening the vote for the RFC on Tuesday.

Right now, I am not going to be in favour of this. Specfically because 
the Backward Incompatible Changes don't list some of the backward 
breaking changes, and no mitigations are provided. See below.

I also don't see the benefit from doing this in the first place. 
exit/die has always meant "bail straight out", without any function 
semantics (from https://www.php.net/exit):

exit — Output a message and terminate the current script

exit is a language construct and it can be called without 
parentheses if no status is passed.

It's not that this a particularly new or novel behaviour.

I saw somewhere else in the thread that the exit construct could already 
throw a catchable exception. I consider that a bug.

> As mentioned early on in private, I don't see a convincing reason to 
> remove tokenizer/parser support for exit/die. I'd rather see this 
> handled in the parser directly, by converting the standalone keywords 
> to function calls. This avoids any backwards incompatibility, and 
> avoids special handling in zend_compile_const.
> 
> Another thing that's probably not too important: The PR likely breaks 
> dead code elimination for exit() and die().

I have just checked this for Xdebug, and you're definitely right with 
that. With the removal of the ZEND_EXIT opcode, it can not now detect a 
scope/function exit now.

It also breaks my "do tasks on ZEND_EXIT" with the profiler. It is used 
to always write the closing profiling footer to the files. Without me 
being able to overload thati opcode, data would not be complete.
I even have two bugs (with tests) for this:

- https://bugs.xdebug.org/68
- https://bugs.xdebug.org/631 

Xdebug has been overloading ZEND_EXIT for nearly 20 years now.

> This could be re-added by checking for the never return type instead.

I can't quite see a way on how to do that? The EXIT is replaced by an 
INIT_FCALL/DO_ICALL:

 4 0  E >   EXT_STMT
   1ECHO'55'
 5 2EXT_STMT
-  3  > EXIT
-6 4*   EXT_STMT
-  5*   ECHO'675'
-7 6*   EXT_STMT
-  7* > RETURN  null
+  3INIT_FCALL  'exit'
+  4DO_ICALL
+6 5EXT_STMT
+  6ECHO'675'
+7 7EXT_STMT
+  8  > RETURN  null

The opcodes don't have direct access to the type mask structure as far 
as I know.

cheers,
Derick

[PHP-DEV] Subject Prefixes

[Derick Rethans]

Hi!

I've noticed that lately, people are adding a [Discussion] prefix to new 
threads to this list. That seems rather superfluous, as this is a 
*discussion* mailing list.

RFCs require us to use [RFC] and [Vote] to stand out, but please let us 
proliferate additional ones.

The normal subject text should be enough.

This is more useful where display space (like on phones) is small, so 
the subject is more easily seen.

cheers,
Derick

Re: [PHP-DEV] Stricter requirements for libxml

[Derick Rethans]

On Fri, 10 May 2024, Niels Dossche wrote:

> Hi internals
> 
> Libxml is used as the underlying library for many PHP extensions.
> Interestingly, libxml can be built with supports for various features 
> disabled.
> E.g. you can build libxml without XPath, Schemas, HTML, ... support.
> In that case, these features are unavailable in PHP. E.g. some classes may 
> not be defined or functions may emit a warning instead of performing an 
> action.
> 
> I'm thinking of proposing an RFC that puts stricter requirements on libxml at 
> build time.
> That would make such features a requirement during PHP's build process.
> This will simplify maintenance and will also make sure that users can rely on 
> these functionalities to always be available.
> 
> Please let me know what you think.

That seems sensible. Did you find any Linux distribution that actively 
disables these features, or is this a "just in case" kind of change?

cheers,
Derick

Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath

[Derick Rethans]

On Tue, 7 May 2024, Gina P. Banyard wrote:

> On Tuesday, 7 May 2024 at 15:46, Saki Takamachi  wrote:
> 
> > On Tue, 7 May 2024, Gina P. Banyard wrote:
> >
> > > - Are the existing BCMath function going to be adapted to handle 
> > > the new Number object or not?
> > 
> > No, that is not considered at this time.
> 
> I am struggling to see a reason for not considering this.

I think that would cause confusion, as BCMath/Number objects do not work 
with the global define scale (for good reasons) and bcmath* functions 
do.

I think I am in favour of a clean "break" here.

cheers,
Derick

Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers

[Derick Rethans]

On Thu, 9 May 2024, Matteo Beccati wrote:

> Il 03/05/2024 11:14, Matteo Beccati ha scritto:
> > 
> > I've updated once again the RFC and implemented most of the 3 major 
> > dialects (mysql, pgsql, sqlite) in the drivers.
> > 
> > https://wiki.php.net/rfc/pdo_driver_specific_parsers
> > 
> > https://github.com/php/php-src/pull/14035
> > 
> > I've tried to keep syntax changes we might not want as separate commits in
> > the PR.
> > 
> > For example:
> >   - the pdo_pgsql driver now also understands C-style escape strings and
> > dollar quoted strings.
> >   - pdo_sqlite supports Access-style [identifiers].
> >   - pdo_mysql will consider "--" a comment only when followed by whitespace.
> > 
> > The latter has been a particular challenge for me and I've been able to
> > overcome it by using the re2c:eof feature, which I then discovered being
> > available only in a later version compared to our requirements (1.2.1,
> > released Aug 2019). As is, the Windows build fails on GH because the sdk
> > ships with 1.1.1.
> > 
> > Perhaps someone with better re2c knowledge can get it working with re2c
> > 1.0.3+, or perhaps it's not really worth it.
> > 
> > Looking forward to hearing from you!
> 
> I didn't see this sparking up discussion, so it either went unnoticed, or
> everybody is fine with it (even the re2c version bump) ;-)

I left a comment about that:
https://github.com/php/php-src/pull/14035#pullrequestreview-2047992559

> In any case I'm planning to start the vote in about 2 weeks from now. 
> Next week I'll be organising phpday in Verona, so feel free to 
> approach me if you are around and have any questions.
> 
> I might even try go get out of my comfort zone and do a lightning talk 
> on the topic. That would be a first in 20+ years of conference 
> organisation... we'll see!

That'd be handy. I'll see you there :-)

cheers,
Derick

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Derick Rethans]

On Thu, 9 May 2024, Flávio Heleno wrote:

> On Thu, May 9, 2024 at 7:51 AM Niels Dossche 
> wrote:
> 
> > On 08/05/2024 15:40, Gina P. Banyard wrote:
> > > Hello Internals,
> > >
> > > I would like to formally propose my idea for exit() as a function 
> > > brought up to the list on 2024-02-24 [1] with the following RFC: 
> > > https://wiki.php.net/rfc/exit-as-function
> > >
> > > There have been some slight tweaks to the implementation, namely 
> > > that the transformation from a "constant" to a function is done at 
> > > compile time and we do not hook into the behaviour of constants 
> > > any longer.
> > >
> > > Let me know what you think.
> >
> > Thanks for proposing this, I'm in favor of this change because this 
> > creates more consistency.
> 
> Is there a list of other "functions" that are handled as "constants"?

I don't think there are any other "functions" like this.

That's why removing the special case for "exit" and "die" is a good 
idea.

cheers,
Derick

Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Derick Rethans]

On Fri, 3 May 2024, Gina P. Banyard wrote:

> On Thursday, 2 May 2024 at 21:33, Derick Rethans  wrote:
> 
> > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote:
> > 
> > > These methods accept an integer to retrieve a parameter by its 
> > > position, or a string to retrieve by its name. So far, I have 
> > > built this so that if you required the first parameter, it's 
> > > parameter 0. I treat it this way because the only other place 
> > > where we deal with parameter indexes, is 
> > > ReflectionFunctionAbstract::getParameters() which returns the 
> > > parameters zero-indexed.
> > > 
> > > The question that is holding this PR back is should these methods 
> > > be 1 indexed, so that the provided position is consistent with the 
> > > error messages, or how a person would typically count, or should 
> > > they be 0 indexed to remain consistent with the existing API.
> > 
> > 0-indexed, as that's what PHP does everywhere else.
> 
> Well not really, if you have an error (TypeError or ValueError) which 
> indicate what parameter is the problem, it will be 1-indexed.

Which *API* in PHP is 1-indexed?

cheers,
Derick

Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Derick Rethans]

On 2 May 2024 13:48:36 BST, Ollie Read  wrote:

>These methods accept an integer to retrieve a parameter by its position, or a 
>string to retrieve by its name. So far, I have built this so that if you 
>required the first parameter, it's parameter 0. I treat it this way because 
>the only other place where we deal with parameter indexes, is 
>ReflectionFunctionAbstract::getParameters() which returns the parameters 
>zero-indexed.
>
>The question that is holding this PR back is should these methods be 1 
>indexed, so that the provided position is consistent with the error messages, 
>or how a person would typically count, or should they be 0 indexed to remain 
>consistent with the existing API.

0-indexed, as that's what PHP does everywhere else. 

cheers
Derick 

[PHP-DEV] [RFC] [VOTE] Release cycle update

[Derick Rethans]

Hi,

the voting for the "Release cycle update" RFC 
(https://wiki.php.net/rfc/release_cycle_update#proposed_voting_choices) 
has now ended.

Each provision has been accepted:

Allow features that do not require an RFC in the beta period:
34 yes - 0 no

Disallow New Features in Release Candidates and Bug Fix releases 
32 yes - 0 no

Reduce number of RCs to Four 
30 yes - 3 no

Extend Security Support by One Year
31 yes - 0 no

Allowing recent regression fixes during security support
30 yes - 0 no

Extend Releases Cycle to End of Year
33 yes - 0 no

Thanks for voting!

I'll update the relevant policy documents shortly.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Derick Rethans]

On Fri, 5 Apr 2024, Tim Düsterhus wrote:

> Hi
> 
> I've just written up the follow-up RFC to my previous “Casing of acronyms in
> class and method names” thread and I'm officially opening up the discussion
> period for it.

One example is the PCGOneseq128XSLRR64 mentioned above

That is probably not the best example of a "readable" class name, as no 
matter the casing, it's not readable :-)

None, yet. This RFC will result in changes to: 

The 
https://github.com/php/php-src/blob/536305436f44e91731bc5c86e06f137e44a01109/CODING_STANDARDS.md#L173-L211
 
document should probably be folded into 
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst 
— having it in two places isn't great.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Incorrect terminology usage for rounding modes of round()

[Derick Rethans]

On 14 April 2024 16:55:43 BST, Saki Takamachi  wrote:
>Hi Gina,
>
>> Hello internals,
>> 
>> While reviewing the PR for the "Adding bcround, bcfloor and bcceil to 
>> BCMath" RFC [1] with the different rounding modes,
>> I was made aware of the unfortunate wrong terminology usage of 
>> PHP_ROUND_HALF_UP and PHP_ROUND_HALF_DOWN.
>> 
>> Indeed, PHP_ROUND_HALF_UP is implemented as "rounding half away from zero" 
>> and not "rounding half up" (which is also called rounding toward positive 
>> infinity).
>> The behaviour for positive numbers is the same, however for negative numbers 
>> the rounding *is* different.
>> In the same vein, PHP_ROUND_HALD_DOWN is implemented as "rounding half 
>> toward zero" and not "rounding half down" (/round half toward negative 
>> infinity).
>> 
>> Taking -1.5 as our number:
>> - Rounding half-up: -1
>> - Rounding half away from zero: -2
>> - Rounding half-down: -2
>> - Rounding half towards zero: -1
>> 
>> For a detailed explanation about rounding, the Wikipedia page is of great 
>> use. [2]
>> And the following rounding calculator on Calculator Soup is useful to check 
>> the differences and behaviour of different rounding modes. [3]
>> 
>> It should be noted that PHP is in good company about being wrong about those 
>> two rounding modes, Java, Python, and Ruby (and probably others) are also 
>> wrong in this regard.
>> 
>> Considering that PHP 8.4 is also adding new rounding modes via the "Add 4 
>> new rounding modes to round() function" RFC [4] attempting to solve this 
>> issue in this next version of PHP seems like a good idea.
>> In my discussions with Saki about this issue, it seems that her and Tim have 
>> thought about creating a new enum for rounding modes, looking something like 
>> this:
>> 
>> enum RoundingMode {
>>case HalfAwayFromZero;
>>case HalfTowardsZero;
>>case HalfEven;
>>case HalfOdd;
>>case TowardsZero;
>>case AwayFromZero;
>>case NegativeInfinity; // or case Floor;
>>case PositiveInfinity; // or case Ceiling;
>> }
>> 
>> and change the signature of round from:
>> round(int|float $num, int $precision = 0, int $mode = PHP_ROUND_HALF_UP): 
>> float
>> to
>> round(int|float $num, int $precision = 0, RoundingMode $mode = 
>> RoundingMode::HalfAwayFromZero): float
>> 
>> and changing the definition of the existing constants to effectively be:
>> define('PHP_ROUND_HALF_UP', RoundingMode::HalfAwayFromZero);
>> define('PHP_ROUND_HALF_DOWN', RoundingMode::HalfTowardsZero);
>> define('PHP_ROUND_HALF_EVEN', RoundingMode::HalfEven);
>> define('PHP_ROUND_HALF_ODD', RoundingMode::HalfOdd);
>> 
>> This should not cause any BC breaks, while allowing us to potentially 
>> implement the half up/down rounding modes properly, and deprecate the 
>> existing rounding constants in the future to get rid of the confusing names.
>> 
>> I wanted to know if anyone has any object to introducing this new enum and 
>> signature change.
>> The only thing I could think of is if this enum should be in a new Maths (or 
>> Math or just Mathematics to not need to deal with regional difference in the 
>> short spelling of "Mathematics") namespace.
>> 
>> Best regards,
>> 
>> Gina P. Banyard
>> 
>> [1] https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
>> [2] https://en.wikipedia.org/wiki/Rounding
>> [3] 
>> https://www.calculatorsoup.com/calculators/math/rounding-methods-calculator.php
>> [4] https://wiki.php.net/rfc/new_rounding_modes_to_round_function
>
>In my discussions with Tim, I want to make it clear that all ideas derived are 
>Tim's. :)
>
>Now, of course I agree with this, and agree with using namespaces. However, if 
>didn't use namespaces, that's fine by me. For reference, we found 
>approximately 100 pieces of code using the namespace `Math` on Github Code 
>Search. There are only a few cases for `Maths` and 0 for `Mathematics`.
>
>Regards,
>
>Saki

Math is American English spelling, Maths/Mathematics the British English one.

As we also have color (and not the "correct" colour), going with the American 
spelling seems better. 

But I would query whether we actually need it in a namespace. 

cheers
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Derick Rethans wrote:

> What do y'all think about requiring GPG signed commits for the php-src 
> repository?
> 
> I had a look, and this is also something we can enforce through GitHub 
> as well (by using branch protections).

It seems that most of the reply to this was positive, although with the 
realisation that it wouldn't be a panacea.

I will therefore propose a minimalistic RFC to create this requirement 
to sign commits to all branches, in the next few days.

 I probably would have prefered requiring *GPG* signing (due to a web of 
trust), but GitHub's requirement isn't that granuar (it's either 
SSG+GPG, or nothing).

Any other opinions, I'd be delighted to hear them.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

[Derick Rethans]

On Wed, 3 Apr 2024, Jordan LeDoux wrote:

> On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP] 
> wrote:
> 
> >
> > Where things get more complicated is with *fixed-precision* decimals,
> > which is what is generally wanted for something like money. What is the
> > correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)?
> > decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about decimal(10) /
> > 3?
> >
> > If you stick to functions / methods, this is slightly less of an issue,
> > because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN) ==
> > decimal(0.51, 2); or decimal(1.03, 2)->split(2) == [ decimal(0.52, 2),
> > decimal(0.51, 2) ] Example names taken directly from the brick/money
> > package.
> >
> > At that point, backwards compatibility is less of an issue as well: make
> > the new functions convenient to use, but distinct from the existing ones
> >
> I came back to this discussion after my last reply on the BCMath as an
> object thread, because we went through a very similar discussion there with
> regard to operators.
> 
> I think that, roughly, the fixed precision should be defined on the scalar
> itself:
> 
> 1.234_d3
> 
> 1.234 is the value, _d makes it a decimal type, and 3 shows that this value
> has a precision of 3. (Actually, it has a SCALE of 3, since precision is
> significant digits, and also includes the integer portion). But when it
> comes to fixed-precision values, it should follow rules very similar to
> those we discussed in the BCMath thread:

Woound't it be much better to capture this complex information in an 
Object, and then allow operators on this? Like... Saki was pretty much 
suggesting with her BCMatch/Number class RFC?

I can't imagine people looking at code understanding a syntax like this 
right away, let alone of what it all means.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

[Derick Rethans]

On Thu, 7 Dec 2023, Alex Pravdin wrote:

> Accounting for all of the above, I suggest adding a native numeric 
> scalar arbitrary precision type called "decimal". Below are the 
> preliminary requirements for implementation.

Adding a new native type to PHP will create a large change. Not only is 
it "just" adding a new native type, it also means all of the conversions 
between types need to be added. This is not a small task.

> Decimal values can be created from literals by specifying a modifier or using
> the (decimal) typecast:
> 
> $v = 0.2d;
> $v = (decimal) 0.2; // Creates a decimal value without intermediary float
> 
> It uses the precision and scale defined in php.ini.

If you want to use arbitrary precision natives, then a precision and 
scale as defined in php.ini defeats the purpose. Every installation can 
then potentially calculate things in a different way.

The only way how to prevent that, is to have *actual* Decimal type, such 
as the Decimal type in MongoDB uses (the IEEE 754 decimal128 type):

- 
https://www.mongodb.com/docs/mongodb-shell/reference/data-types/#std-label-shell-type-decimal
- https://en.wikipedia.org/wiki/Decimal128_floating-point_format

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

[PHP-DEV] [VOTE] [RFC] Release cycle update, take #2

[Derick Rethans]

Hi,

there have been no further comments on the release cycle update RFC 
thread, so I'm hereby opening the RFC for voting.

Voting will end on Monday April 29th, at noon UTC (20 days, instead of 
the required minimum of 14):

https://wiki.php.net/rfc/release_cycle_update#proposed_voting_choices

cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

[Derick Rethans]

On 5 April 2024 15:09:42 CEST, Joel Wurtz  wrote:
>Hello everyone,
>
>Like a lot of libraries, we offer the possibility to configure behaviors
>with Attributes. However in some cases it's wrongly configured by the user
>and this wrong configuration cannot be detected on the attribute
>constructor but afterwards.
>
>In this case we may want to pinpoint which attribute (in which file and at
>which line) cause this bad configuration. Since there was no method to
>retrieve those information in the ReflectionAttribute I proposed a PR
>https://github.com/php/php-src/pull/13889 to add those informations.
>
>I do believe this will allow better DX for end user when correctly used,

Would it make sense to not only add this for ReflectionAttribute, but also 
Function and/or others?

Functions have a range of lines associate with them. Could Attributes have that 
too?

cheers
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, John Coggeshall wrote:

> 
> > So if we want to make sure that something like XY doesn't happen, we
> > have to add some additional restrictions to those GPG keys.
> 
> Looks like all those geeky colleagues of ours back in the day having 
> key-signing parties at conferences were on to something, maybe..

> Let's be clear about something -- having GPG key requirements isn't 
> going to help a situation like XZ. The XZ attack was done by an active 
> maintainer of the project (who arguably manipulated the original 
> maintainer of the project to become a maintainer themselves). It was 
> as much a social engineering attack as anything.

> Having GPG key requirements is all fine and dandy I suppose, but my 
> tongue-in-cheek comment above has a real point behind it: GPG keys 
> don't mean jack if you can't trust who owns the key.

GitHub doesn't show the web of trust anyway, just "verified". Command 
line GIT doesn't either, just:

$ git verify-commit HEAD~1
gpg: Signature made Tue 02 Apr 2024 14:55:21 BST
gpg:using RSA key 5A52880781F755608BF815FC910DEB46F53EA312
…
gpg: aka "Derick Rethans (GitHub) " 
[ultimate]
gpg: aka "Derick Rethans (PHP) " [ultimate]


cheers,
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Ayesh Karunaratne wrote:

> > What do y'all think about requiring GPG signed commits for the 
> > php-src repository?
> >
> > I had a look, and this is also something we can enforce through 
> > GitHub as well (by using branch protections).
> 
> +1 from me as well, and quite good timing with all the xz fiasco just 
> last week.
> 
> Git can also sign with SSH keys now, so this is now merely a config 
> update

The issue with SSH keys is that they can not be signed by others to form 
a "web of trust". For example, my key has been signed by several other 
people:

https://keyserver.ubuntu.com/pks/lookup?search=derick%40php.net=on=index

cheers,
Derick

Re: [PHP-DEV] First time contributor (DateTime::setDate PR)

[Derick Rethans]

On Tue, 2 Apr 2024, Bilge wrote:

> On 02/04/2024 14:14, Derick Rethans wrote:
> > 
> > On Sun, 31 Mar 2024, Bilge wrote:
> > 
> > > About the PR: I sometimes find it would be useful to only update 
> > > part of the date. The PR makes all parameters to 
> > > DateTime(Immutable)::setDate 
> > > <https://www.php.net/manual/en/datetimeimmutable.setdate.php> 
> > > optional in a backwards-compatible manner such that we can elect 
> > > to update only the day, month, year or any combination of the 
> > > three (thanks, in part, to named parameters). Without this 
> > > modification, we must always specify all of the day, month and 
> > > year parameters to change the date.
> > As I mentioned to you in Room 11, I am not in favour of adhoc API 
> > changes to Date/Time classes. It has now been nearly 18 years since 
> > they were originally introduced, and they indeed could do with an 
> > overhaul.
> > 
> > I have been colllecting ideas in 
> > https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3SIxOKWsk/edit#heading=h.2jol7kfhmijb
> > 
> > Having different/better modifiers would also be a good thing to talk 
> > about, albeit perhaps on the four mentioned new classes, instead of 
> > adding them to the already existing DateTime and DateTimeImmutable 
> > classes.
> > 
> > In any case, just allowing setDate to be able to just modify the 
> > month is going to introduce confusion, as this will be counter 
> > intuitive:
> > 
> > $dt = new DateTimeImmutable("2024-03-31");
> > $newDt = $dt->setDate( month: 2 );
> > 
> > It is now representing 2024-03-02.
> > 
> > This might be the right answer, but it might also be that the 
> > developer just cared about the month part (and not the 
> > day-of-month), in which case this is a WTF moment.
> > 
> > Picking mofication APIs is not as trivial as it seems, and I would 
> > like to do it *right*.
> > 
> > Feel free to add comments and wishes to the google doc document. In 
> > the near future, I will be writing up an RFC from this.
> 
> Thanks for your reply!
> 
> Indeed, as per your code snippet, this is a WTF moment I had not accounted for
> and confirm the same result with my patch applied. Generally, my expectation
> here would be the month *must* be set to 2, so if the day portion will be
> invalidated by that change, we should either throw an exception or implicitly
> coerce it into range, i.e. (new DateTime("2024-03-31"))->setDate(month: 2); ==
> 2024-02-29.

We can't do that, as it will be inconsistent with:

modify("+1 month")
// (also 2024-03-02)

> However, I suppose this is not the conversation we're having as
> you do not wish to change this API at all, which I respect.

I think what you're actually after here, is a "YearMonth" type, which 
doesn't concern itself with the day-of-month at all. Setting just the 
month should perhaps just reset the day-of-month to 1 instead. ANd 
setting just the year would result in January 1st, as well.

> Regarding your brainstorm document, I can't understand much of it in its
> current state, and as I am not a subject matter expert, I think you will
> receive much better feedback from others.

It isn't particularly organised yet, and... I also haven't made sense of 
all of it yet.

> In particular, I cannot glean which four classes you are referring to 
> in that document. Yet what I do find interesting is the notion of 
> adding setters to DateTimeImmutable. For my particular 
> use-case—producing a collection of dates incrementing by year in a 
> Twig template—a trivial year setter would do just fine, with the 
> significant caveat that it must implement fluent interface, because I 
> need to call it in an expression context (returning a value), not a 
> statement context (executing a void function separately). Not that 
> Twig cannot execute statements, but it just becomes more verbose, 
> cumbersome and less template-like.
> 
> If you were happy for me to add getters and fluent setters for year, 
> I'd be happy to work on that PR, but for month we're back to the same 
> problem outlined in the opening paragraph (and I suppose the same 
> problem occasionally applies to year, if the day happens to be set to 
> the leap day). Otherwise, I'll be happy to read over your RFC when 
> it's ready.

Feel free to add your suggestion (anywhere) in the document, preferrably 
at the bottom :-)

I can envision that we'll have some actual setters and getters, beyond 
just add, sub, and modify (which is really powerful).

But what is important to understand is rather *why* a specific method is 
useful, and perhaps even more important is what you're actual goal is.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Calvin Buckley wrote:

> On Apr 2, 2024, at 11:15 AM, Derick Rethans  wrote:
> > 
> > What do y'all think about requiring GPG signed commits for the php-src 
> > repository?
> > 
> > I had a look, and this is also something we can enforce through GitHub 
> > as well (by using branch protections).
> 
> Would this affect only direct pushes to master, or would it be required
> for pull requests too? I'd be worried the average drive-by contributor
> wouldn't have GPG signing set up.

As Ayesh said, you can also use SSH for this now:
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification

I think it would apply to people merging the commits. But, I am not 100% 
sure (until we try, I suppose).

cheers,
Derick



-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

[PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

Hi,

What do y'all think about requiring GPG signed commits for the php-src 
repository?

I had a look, and this is also something we can enforce through GitHub 
as well (by using branch protections).

cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

[Derick Rethans]

On Sat, 30 Mar 2024, Jakub Zelenka wrote:

> On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta  wrote:
> >
> > I understand that the XZ project had signed releases too: that still 
> > means that downstream consumers would need to trust the release 
> > managers anyway, and reproduce the whole chain themselves.
> >
> > I suppose that's part of OP's concern.
> >
> I agree that compromised RM is a problem that we should look into.
> 
> We have been actually already discussing something similar. I have 
> been thinking about it and it could be potentially used for all 
> builds. The idea is that we would setup worklfow on CI that would run 
> on tag push and it would call (authenticated https request) 
> downloads.php.net server that could do the actual build, sign them and 
> return the hashes to the CI job which would display them and do extra 
> verification (probably its own build to verify that download server 
> work as expected).

...

> It needs more thinking to iron out all details and make sure it is a 
> secure but I think it would be something worth to look at.

I don't mind coming up with an automated way, but we probably should not 
use the *downloads* server. All it does is serve files. It has no 
compiler or anything else. It's a storage optimised instance with little 
CPU.

On CI we already test the builds, what does stop us from also just 
having it make the tarball and attach it as an artefact? We can then 
setup somethin gon the downloads server to pull these artefacts. In 
fact, this is exactly what we're already hoping to do for Windows 
downloads too. Having it all in one place is probably even better (and 
easier).

Of course, having CI make the tarballs means we need to trust that CI 
isn't compromised ;-).

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Derick Rethans]

On Fri, 29 Mar 2024, Jordan LeDoux wrote:

> On Wed, Mar 27, 2024 at 12:08 AM Aleksander Machniak  wrote:
> 
> > On 27.03.2024 01:03, Saki Takamachi wrote:
> > >> $num = new BcNum('1.23', 2);
> > >> $result = $num + '1.23456';
> > >> $result->value; // '2.46456'
> > >> $result->scale; // ??
> > >
> > > In this case, `$result->scale` will be `'5'`. I added this to the 
> > > RFC.
> >
> > I'm not sure I like this. Maybe we should be more strict here and 
> > treat the $scale in constructor (and later withScale()) as the 
> > actual scale for all operations.
> >
> >
> For addition, it absolutely should expand scale like this, unless the 
> constructor also defines a default rounding type that is used in that 
> situation. All numbers, while arbitrary, will be finite, so addition 
> will always be exact and known based on inputs prior to calculation.
> 
> Treating scale like this isn't more strict, it's confusing. For 
> instance:
> 
> ```
> $numA = new Number('1.23', 2);
> $numB = new Number('1.23456', 5);
> 
> $expandedScale1 = $numA + $numB; // 2.46456
> $expandedScale2 = $numB + $numA; // 2.46456
> 
> $strictScale1 = $numA + $numB; // 2.46 assuming truncation
> $strictScale2 = $numB + $numA; // 2.46456
> ```
> 
> I ran into this same issue with operand ordering when I was writing my 
> operator overload RFC.
> 
> There are ways you could do the overload implementation that would get 
> around this for object + object operations, but it's also 
> mathematically unsound and probably unexpected for anyone who is going 
> to the trouble of using an arbitrary precision library.
> 
> Addition and subtraction should automatically use the largest scale 
> from all operands. Division and multiplication should require a 
> specified scale.

I agree. I think add/subtract also should always take the largest scale 
here.

cheers,
Derick

Re: [PHP-DEV] First time contributor (DateTime::setDate PR)

[Derick Rethans]

Hi,

On Sun, 31 Mar 2024, Bilge wrote:

> About the PR: I sometimes find it would be useful to only update part of the
> date. The PR makes all parameters to DateTime(Immutable)::setDate
>  optional in a
> backwards-compatible manner such that we can elect to update only the day,
> month, year or any combination of the three (thanks, in part, to named
> parameters). Without this modification, we must always specify all of the day,
> month and year parameters to change the date.

As I mentioned to you in Room 11, I am not in favour of adhoc API 
changes to Date/Time classes. It has now been nearly 18 years since they 
were originally introduced, and they indeed could do with an overhaul.

I have been colllecting ideas in 
https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3SIxOKWsk/edit#heading=h.2jol7kfhmijb

Having different/better modifiers would also be a good thing to talk 
about, albeit perhaps on the four mentioned new classes, instead of 
adding them to the already existing DateTime and DateTimeImmutable 
classes.

In any case, just allowing setDate to be able to just modify the month 
is going to introduce confusion, as this will be counter intuitive:

$dt = new DateTimeImmutable("2024-03-31");
$newDt = $dt->setDate( month: 2 );

It is now representing 2024-03-02.

This might be the right answer, but it might also be that the developer 
just cared about the month part (and not the day-of-month), in which 
case this is a WTF moment.

Picking mofication APIs is not as trivial as it seems, and I would like 
to do it *right*.

Feel free to add comments and wishes to the google doc document. In the 
near future, I will be writing up an RFC from this.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

On Fri, 22 Mar 2024, Morgan wrote:

> On 2024-03-22 08:19, Jim Winstead wrote:
> > On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:
> > > 
> > > The RFC is at https://wiki.php.net/rfc/release_cycle_update
> > 
> > Could this RFC also be a good time to clarify what sort of BC changes are
> > actually allowed in major and minor releases, or should we save that for a
> > different RFC? (Because it's already been acknowledged that the current
> > written policy doesn't align with the practiced policy, and I think it would
> > be nice to get those in sync.)
> > 
> If so, would it also good time/place to clarify how deprecation relates to
> future removal. Say, while deprecations could come in any minor release, they
> would be removed only after a full major version has elapsed (something
> deprecated in 8.x would be removed in 10.0; technically that would mean a
> deprecation in 9.0.0 would also mean removal in 10.0). It would allow using
> the overall release cycle to forecast when something you're currently relying
> on will go away and plan accordingly.

The current "rule" is that we can remove deprecated features in any 
x.0.0 release 
(https://github.com/php/policies/blob/main/release-process.rst#releases-cycle).

I am not proposing to change that with this RFC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

On Thu, 21 Mar 2024, Jim Winstead wrote:

> On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:
> > Hi!
> >
> > On Fri, 10 Nov 2023, Jakub Zelenka wrote:
> >
> >> I would like to propose a new process RFC for updates to PHP release 
> >> cycle:
> >> 
> >> https://wiki.php.net/rfc/release_cycle_update
> >
> > I have just published version 0.2 of this proposal — I am taken this 
> > over from Jakub by agreement.
> >
> > I've slightly reordered it, addressed some comments from this thread, 
> > and added one new item: aligning the end of releases until Dec 31st, 
> > 20xx.
> >
> > Now that we have policy documents, my next step is to prepare PRs to 
> > https://github.com/php/policies/blob/main/feature-proposals.rst for each 
> > item, after a more general reset of the document to reflect current 
> > practises.
> >
> > The RFC is at https://wiki.php.net/rfc/release_cycle_update
> 
> Could this RFC also be a good time to clarify what sort of BC changes 
> are actually allowed in major and minor releases, or should we save 
> that for a different RFC? (Because it's already been acknowledged that 
> the current written policy doesn't align with the practiced policy, 
> and I think it would be nice to get those in sync.)

I'm planning in doing a rewrite of the whole policy document on releases 
(https://github.com/php/policies/blob/main/release-process.rst) and then 
RFCing the changes. That document also contains as to what a bug fix is.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

On Thu, 21 Mar 2024, Daniil Gentili wrote:

> >> I would like to propose a new process RFC for updates to PHP release
> >> cycle:
> >>
> >> https://wiki.php.net/rfc/release_cycle_update
> 
> I would also like to propose an addition, allowing patch releases to 
> be made outside of the normal release schedule if a major core feature 
> is broken by a fix in the previous patch release.
> 
> These out-of-schedule releases should only contain a clean revert of 
> the fix that broke the major core feature.
> 
> I believe the "major core feature" set should include at least the 
> garbage collector and string functions, it may be extended if needed.
> 
> I'm advocating for this change due to the fact that critical garbage 
> collector bugs were introduced and released at least twice in the last 
> year:
> 
> - First with a GC patch that completely broke garbage collection 
>   causing segfaults if fibers are used 
>   (https://github.com/php/php-src/pull/9810)
> - And then with a GC patch 
>   that broke garbage collection causing segfaults when using weakmaps 
>   (https://github.com/php/php-src/pull/10932)
> 
> Specifically regarding the first bug, the fix for it was actually 
> delayed by 30 days, instead of 15 (the time left until the next 
> release, when the fix PR was merged), as a security release was made 
> the day after the fix was merged, delaying the entire release cycle by 
> 30 days.

Security releases have no impact on this.

> I believe that bugs in major core features, introduced by fix PRs 
> should be reverted ASAP, especially if they aren't noticed until a 
> release, instead of breaking a core feature of the language for one 
> month (or more if a security release delays the normal release cycle).

I find this out of the scope of this RFC. I also believe that this is 
not a common occurence.

 
> Also in general, I find it wrong that security releases should delay 
> the normal cycle.

They don't? A security release is just a label in addition to a "normal" 
release, in case there are bug fixes that warrant us calling them 
security issues.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Derick Rethans]

On Wed, 27 Mar 2024, Saki Takamachi wrote:

> > - You've picked as class name "BcNum". Following
> >  our naming guidelines, that probably should be \BCMath\Num (or 
> >  \BC\Num, but that is less descriptive): 
> >  
> > https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces-in-extensions
> > 
> >  The reason it *should* have "BC" is that it comes from "Basic 
> >  Calculator" (https://www.php.net/manual/en/book.bc.php#118203)
> 
> 
> I re-read the namespace RFC again. I also re-read the RFC regarding 
> class naming conventions. 
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions 
> https://wiki.php.net/rfc/class-naming
> 
> There's no need for the namespace to follow class naming conventions, 
> but the acronym doesn't seem to need to be pascal-case anyway (I 
> remembered it incorrectly). However, the RFC states that the 
> extension's namespace must match the extension name, so it seems 
> correct in this case for the namespace to be `BCMath`.
> 
> And indeed, looking at the example in the namespace RFC, 
> `BCMath\Number` might be appropriate in this case (I think I was 
> sleepy yesterday).
> 
> I changed `BcNum` to `BCMath\Number` in my RFC.

That works fine as well. Especially as most people would add:

use BCMath\Number as Number;

and then just use "Number" everywhere.

> > - Should ->value rather be ->toString() ? ->value alone doesn't 
> > really
> >  say much. I'm on the fence here though, as there is already 
> >  (internally) a ->__toString() method to make the (string) cast 
> >  work.
> 
> What is the main difference between getting a read-only property with 
> `->value` and getting the value using a method?

Feeling :-) Do we have precedence with other extension's objects 
perhaps already?

> > - Would it make sense to have "floor" and "ceil" to also have a scale, 
> >  or precision? Or would developers instead have to use "round" in 
> >  that case?
> 
> > - Which rounding modes are supported with "round", the same ones as 
> > the
> >  normal round() function?
> 
> `bcfloor` and `bcceil` originally have no scale specification. This is 
> because the result is always a string representing an integer value. 
> And since the supported round-mode is the same as standard-round, 
> `ROUND_FLOOR` and `ROUND_CEILING` are also supported. Therefore, if 
> want to obtain floor or ceil behavior with a specified scale, I 
> recommend specifying the mode as round.

OK. That makes sense.

> > - In this example, what would $result->scale show? (Perhaps add that to 
> >  the example?):
> > 
> >  > $num = new BcNum('1.23', 2);
> > $result = $num + '1.23456';
> > $result->value; // '2.46456'
> > $result->scale; // ??
> 
> In this case, `$result->scale` will be `'5'`. I added this to the RFC.

Great. 

> > - Exceptions
> > 
> >  The RFC does not mention which exceptions can be thrown. Is it just 
> >  the one? It might be beneficial to *do* have a new exception 
> >  hierarchy.
> 
> 
> As far as I know right now, following exceptions can be thrown:
> 
> - Value error when a string that is invalid as a number is used in a 
>   constructor, calculation method, or operation
> - Divide by 0 error (include Modulo by zero)
> 
> I was thinking that it would be a bad idea to increase the number of 
> classes without thinking, and was planning to use general exceptions, 
> but would it be better to use dedicated exceptions?

It's what we did for the Date extension, and the Random extension, but 
in this case, it's probably not needed as you say.

> By the way, generally when implementing such exceptions in userland, 
> value errors and divide-by-zero errors are probably defined as 
> separate classes, but should they be separated in this case?

For that, yes. ValueErrors should be distinct from DivideByZeroError — I 
think we do have both of those already:

php -r 'echo 8/0;'

Fatal error: Uncaught DivisionByZeroError: Division by zero in Command 
line code on line 1

From the docs for ValueError:

"A ValueError is thrown when the type of an argument is correct but the 
value of it is incorrect."

From the docs for DivisionByZeroError:

" DivisionByZeroError is thrown when an attempt is made to divide a 
number by zero. "

Subclassing these for BCMath objects seems unnecessary therefore.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

[Derick Rethans]

On 27 March 2024 23:18:21 GMT, "Rowan Tommins [IMSoP]"  
wrote:
>On 26/03/2024 21:14, Casper Langemeijer wrote:
>> If you need someone to help for the grapheme_ marketing team, let me know.
>
>I think a big part of the problem is that very few people dig into the 
>complexities of text encoding, and so don't know that a "grapheme" is what 
>they're looking for.
>
>Unicode documentation is, generally, very careful with its terminology - 
>distinguishing between "code points", "code units" "graphemes" , "grapheme 
>clusters", "glyphs", etc. Pretty much everyone else just says "character", and 
>assumes that everyone knows what they mean.

That's why I have been working on 


Takes all the (or most) terminology out of it. 

It's time to resurrect it. 

cheers 
Derick 

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

[Derick Rethans]

On 26 March 2024 17:04:18 GMT, Casper Langemeijer  wrote:
>I'd like to address an issue I have with this RFC.

Please don't top reply. 

>I'm not sure is solves a problem by itself. If I understand all of this 
>correctly this only does what already can be accomplished with 
>preg_match_all('/\X/u', ...). The result of this method in my opinion is not 
>very usefull by itself. I've done some searching on various code platforms 
>where I mostly find the use-case for counting the number of grapheme's. I've 
>used it to implement strrev() that correctly works multibyte. 
>
>I'm very sad that mbstring works on codepoints instead of grapheme's and I 
>would very much like to see something happening in that area, but I think 
>expanding a simple string to an array of as many elements to give developers a 
>tool to do this in PHP-space is not good enough. Especially since it can 
>already be achieved with a regexp that already works.
>
>In my opinion: This adds nothing, and tells the PHP developer that is ok to do 
>count(grapheme_str_split()) for a more accurate mb_strlen().
>
>I would like to see a family of functions that can do multibyte str_split(), 
>strrev(), substr(). Ideally as bugfix in mb_* functions, because the edge-case 
>of wanting to know the length in codepoints of a string is a weird edge-case. 
>No developer wants to know that. mb_strlen() should have returned the number 
>of graphemes from the start.

Many of these already exist, such as grapheme_substr. We can't simply change 
the behaviour of the already existing functions due to BC reasons. 

The intl extension is also built on ICU, an actual unicode text processing 
library. 

The grapheme_str_split function, as well as other intl extension functions is 
what should replace mbstring really. 

cheers 
Derick 

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Derick Rethans]

On Sun, 24 Mar 2024, Saki Takamachi wrote:

> Hi internals,
> 
> I want to start the discussion on the PHP RFC: Support object type in BCMath.
> 
> https://wiki.php.net/rfc/support_object_type_in_bcmath

I have some comments:

- You've picked as class name "BcNum". Following 
  our naming guidelines, that probably should be \BCMath\Num (or 
  \BC\Num, but that is less descriptive): 
  
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces-in-extensions

  The reason it *should* have "BC" is that it comes from "Basic 
  Calculator" (https://www.php.net/manual/en/book.bc.php#118203)

- Should ->value rather be ->toString() ? ->value alone doesn't really 
  say much. I'm on the fence here though, as there is already 
  (internally) a ->__toString() method to make the (string) cast work.

- Would it make sense to have "floor" and "ceil" to also have a scale, 
  or precision? Or would developers instead have to use "round" in that 
  case?

- Which rounding modes are supported with "round", the same ones as the 
  normal round() function?

- In this example, what would $result->scale show? (Perhaps add that to 
  the example?):

value; // '2.46456'
$result->scale; // ??

- Exceptions

  The RFC does not mention which exceptions can be thrown. Is it just 
  the one? It might be beneficial to *do* have a new exception 
  hierarchy.



cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

[PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

Hi!

On Fri, 10 Nov 2023, Jakub Zelenka wrote:

> I would like to propose a new process RFC for updates to PHP release 
> cycle:
> 
> https://wiki.php.net/rfc/release_cycle_update

I have just published version 0.2 of this proposal — I am taken this 
over from Jakub by agreement.

I've slightly reordered it, addressed some comments from this thread, 
and added one new item: aligning the end of releases until Dec 31st, 
20xx.

Now that we have policy documents, my next step is to prepare PRs to 
https://github.com/php/policies/blob/main/feature-proposals.rst for each 
item, after a more general reset of the document to reflect current 
practises.

The RFC is at https://wiki.php.net/rfc/release_cycle_update

cheers,
Derick

[PHP-DEV] System Upgrades / Rsync Server Swapover

[Derick Rethans]

Hi!

TL,DR:

1. I have just pushed a DNS change to use our new rsync server.
2. I have upgraded main.php.net from Debian 10 to 12
3. I have installed all the latest updates on most machines


Long Form

1. In the beginning of the year, Deft (formerly Server Central), reached 
out to us that the current rsync server is old, and they would like to 
continue sponsoring us with a replacement (faster) machine.

I set up this new server in February, but then the mailing list stuff 
happened and life got in the way, so I have only just switched DNS over 
after testing each property.

Except that I could not test rsync and rmtools, as I don't know where 
they live. Nor PEAR, as I don't have access, and I also don't know 
whether it uses our rsync service.

This change should not cause any issues, but let me know if some 
websites don't update after committing code through Git.

2. main.php.net still ran Debian 10, and now Debian 12. This does come 
with a new PHP version (8.2), and I have changed it to use the system 
PHP instead of using Sury's repostory. Again, I also don't expect this 
to cause issues.

3. It is good to install system update onces in a while, and I've done 
that.

Let me know if anything broke!

cheers,
Derick
-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Windows PECL build machine died

[Derick Rethans]

Hi,

To revive this ancient thread. We have made some progress getting these 
builds made for Windows again.

Shivam has been working on an extension builder for Windows 
(https://github.com/php/php-windows-builder?tab=readme-ov-file#build-a-php-extension)
 
— GHA actions to build your DLLs on release.

He's tried that on Xdebug: 
https://github.com/shivammathur/xdebug/blob/master/.github/workflows/release.yml

This is still pre-release, so please don't rely on this yet!

We are also looking at buliding some specific PECL extensions for 
Windows, and uploading them to the downloads server.

PECL DLLs are no longer served from the windows.php.net server either, 
but instead from downloads.php.net/~windows : 
https://pecl.php.net/package/ssh2/1.3.1/windows

Uploading built DLLs to this server can not be done automatically due to 
2FA requirements, but we'll think on how to improve that.

cheers,
Derick



On Sun, 23 Apr 2023, Casper Langemeijer wrote:

> Nothing seems to happen on this front, and our Windows users like to move to 
> PHP 8.2 too.
> 
> The windows.php.net site states: "This is because the Windows PECL build 
> machine died, and the team is still working on the long term plan of building 
> DLLs for PECL extensions with a new CI process."
> 
> We are 1 year since the machine died. 6 month since the statement on the 
> website. From the point of view of our users nothing has changed, and are 
> questioning if the windows project is still alive.
> 
> I'd like to ask: Is re-inventing the building process really a smart thing to 
> do if it means we'll be out-of-service for more than a year?
> 
> "We're doing our best to finish that as soon as possible, and keep you up to 
> date."
> 
> I'm not questioning intentions, but I hate to think this is 'our best'. We 
> should at least have and share a more concrete plan, possibly share a rough 
> timeframe and share if we hit a blocking problem. If help is needed, we 
> should ask.
> 
> Greetings, Casper

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Derick Rethans]

On Fri, 8 Mar 2024, Larry Garfield wrote:

> Hi folks.  Based on earlier discussions, we've made a number of 
> changes to the RFC that should address some of the concerns people 
> raised.  We also had some very fruitful discussions off-list with 
> several developers from the Foundation, which led to what we feel are 
> some solid improvements.
> 
> https://wiki.php.net/rfc/property-hooks

Some comments and questions:

Be aware, the detection logic works on $this->[propertyName] directly 
at 
compile time, not on dynamic forms of it like $prop = 'beep'; 
$this->$prop. That will not trigger a backing value. 

How can that not cause issues?


 The set hook's return type is unspecified, and will silently be 
treated as void. 

What happens if you *do* specify a return type? Will it Error?


Implicit ''set'' parameter

If the write-type of a property is the same as its defined type 
(this is the common case), then the argument may be omitted 
entirely. 

…

If the parameter is not specified, it defaults to $value.

I am not a fan of this "magical" behaviour. Do we *need* this short cut, 
and the following "Short-set"?


With asymmetric visibility that was previously proposed, the 
example can be further simplified. 

But it isn't here, so why is this example (and the next one) in the RFC? 
:-)


Interaction with constructor property promotion

… In particular, the shorthand version of hook bodies and the 
ability to call out to private methods if they get complicated 
partially obviate the concern about syntactic complexity. 

Although that is true, it *does* add more complexity in tools that needs 
to parse PHP, as there is now another piece of new syntax that needs to 
be added (and tested with).


ReflectionProperty has several new methods to work with hooks.

getHooks(): array returns an array of \ReflectionMethod objects  
keyed by the hook they are for.

What will the name for the  hook be? And shouldn't there be an enum 
case for that as well?

cheers,
Derick

Re: [PHP-DEV] is this thing on?

[Derick Rethans]

On 4 March 2024 22:26:37 GMT, dan...@daniil.it wrote:
>> Has Microsoft made a commitment to support open source forever? I mean MS 
>> owns Github, what ensures that it will stay free?
>
>This is a silly argument, if that were the case, maybe the VCS should move 
>back to a self-hosted instance too?

The VSC part from github (hosting our code), can very easily be ported. Issues, 
discussions etc can not. 

>Jokes aside, if Microsoft suddenly decides to throw away or to charge for 
>github, one of their biggest assets after Windows and OpenAI, PHP would have 
>bigger problems than RFCs being managed on the github issue tracker.

With the ongoing enshittification of most of the Internet due to advertising 
and tracking, we'd be negligent not hosting and owning our own content 
(including our issue tracker, but that ship has sailed now). 

Email has been around for half a century. Will things like Slack, Discord, and 
the like still be operational and allow access to our archives in another 25 
years? I'm almost certain it won't be. 

cheers 
Derick 

Re: [PHP-DEV] is this thing on?

[Derick Rethans]

On 26 February 2024 11:03:05 GMT, "Rowan Tommins [IMSoP]" 
 wrote:
>On Sun, 25 Feb 2024, at 20:02, Rob Landers wrote:
>> Before I get to the meat of this email, first of all, IMHO, anyone should be 
>> able to email the list, even if they are not a 
>> member of the list. I've had to email ubuntu lists about bugs before and I 
>> really have no desire to join those lists, but
>> I was always able to just send the email to the list just fine.

That's not true. There was a complex pre-auth system in use that you had to do 
once (the "confirmed list"). 

>The biggest problem with an open list is how to manage spam

Exactly. See the results of that on the php-announce list which was open for a 
few hours. 

We can't make this an open list. 

>Exactly the same way you subscribed, I believe: via the web form, or using 
>+unsubscribe in the to address.

Correct. 

cheers 
Derick 

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On Thu, 22 Feb 2024, mjec wrote:


On Thu, 2024-02-22 at 10:29 -05:00, Alain D D Williams  
wrote:

On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:

Gmail is rejecting emails after we moved the servers without telling 
us why, in enough detail to do anything about it.


I run other mail lists and have had similar problems with gmail 
recently.


Gmail explicitly tightened their requirements for senders this month, 
so while it's likely the server change is related, it may not be the 
entire cause.


Specifically, they require:

- valid spf, with specific rules for quarantining email that has @gmail.com 
From but doesn't pass spf
- valid dkim
- dmarc configured if the server sends more than 5k emails to Gmail


We should have all of that though?



They also equivocally indicate a requirement for ARC and a List-Id header.


We have a List-Id header, but I've not even heard of ARC. It is on our 
list to investigate though. Our SMTP logs definitely don't say anything 
about this though.



This is all at https://support.google.com/a/answer/81126.

I think ARC is a must; without it we'll never get to passing dkim at 
least, even if we rewrite from so spf passes.


But SPF is now passing? The postmaster tools show this:

Date	DKIM success rate	SPF success rate	DMARC success 
rate

15 Feb 2024 100.0%  100.0%  0.0%
16 Feb 2024 100.0%  100.0%  0.0%
17 Feb 2024 100.0%  100.0%  0.0%
18 Feb 2024 100.0%  100.0%  0.0%
19 Feb 2024 100.0%  100.0%  100.0%
20 Feb 2024 100.0%  100.0%  100.0%

I'm happy to pitch in to help getting this configured if that's 
helpful, though I'm also very conscious that too many cooks is often a 
greater harm than good when it comes to administration. But reach out 
if you think I can be helpful.


We could definitely use some people that now email delivery.

cheers,
Derick

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On Thu, 22 Feb 2024, Alain D D Williams wrote:


On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:


Gmail is rejecting emails after we moved the servers without telling us why, in 
enough detail to do anything about it.


I run other mail lists and have had similar problems with gmail recently.

The problem seems to be SPF. This says which IP addresses can be used for
sending email for particular domains. gmail has recently become much stricter.

List emails are sent from php-smtp4.php.net (45.112.84.5).

However the 'From' address is still that of the original sender -- which is OK
for the email that I am replying to as it is
From: Derick Rethans 

and the MX for php.net is php-smtp4-ip4.php.net. which has address 45.112.84.5

However I suspect that *this* email (the one that I am typing now) will get
bounced by gmail as my address is: a...@phcomp.co.uk and 45.112.84.5 is not
allowed (by SPF) to send email for phcomp.co.uk.

So: how to fix ?

Make the From: address internals@lists.php.net


We don't want to change the From address, as that means that replies go 
to the list, rather than the original sender. We never had to do any of 
that before.



The envelope address is already, something like
internals+bounces-122457-addw=phcomp.co...@lists.php.net

This means a fix to whatever list processor that you are using.

Other recommendations:

• MX for lists.php.net is php-smtp4-ip4.php.net.
Change to php-smtp4.php.net.


Done


• SPF for lists.php.net is "v=spf1 a mx a:osu1php.osuosl.org. ip4:45.112.84.5 
ip6:2a02:cb43:8000::1102"
Change to "v=spf1 a mx -all"


Done, but I kept it as ~all.


•• osu1php.osuosl.org. does not seem to exist - so zap it


Done


•• If you make the MX change that I suggest then the
following are redundant: ip4:45.112.84.5 ip6:2a02:cb43:8000::1102


Done


•• -all means no other addresses accepted. gmail started making that implicit in
the last few months, it is this that is causing the current problems.


I've added ~all instead.

Once that has settled down you should enable sending email from (& 
thus to) IPv6 addresses. This is the way that the world is moving. It 
is not hard.


Done that now too.

Fingers crossed to see if any of this is helping.

cheers,
Derick

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On 22 February 2024 08:52:49 GMT-05:00, Robert Landers 
 wrote:
>I have noticed quite a number of emails appearing on externals but not
>appearing in my inbox. I randomly get an email saying:
>
>Hi, this is the Mlmmj program managing the 
>mailing list.
>
>Some messages to you could not be delivered. If you're seeing this
>message it means things are back to normal, and it's merely for your
>information.
>
>Here is the list of the bounced messages:
>- 122446
>- 122448
>
>But I can clearly see far more than that in externals that are never received.
>
>IIRC from the email spec and internet customs, soft-bounces should be
>retried for a number of days (though I have no idea why gmail
>soft-bounced the messages, maybe rate-limiting?).
>
>If I'm using gmail and not getting emails, how many other people are
>also not getting emails on this list?


Lots.

Gmail is rejecting emails after we moved the servers without telling us why, in 
enough detail to do anything about it.

We can put a delay in delivering to Gmail, but that means mails get delayed for 
days.

So my advice would for now to not rely on Gmail while we figure out how to 
improve this.

cheers
Derick

Re: [PHP-DEV] Requesting RFC karma

[Derick Rethans]

On 20 February 2024 10:05:25 CET, Marc Bennewitz  wrote:
>
>On 20.02.24 09:58, Derick Rethans wrote:
>> On 20 February 2024 08:41:19 GMT, Marc Bennewitz  wrote:
>>> Hi Hans,
>>> 
>>> On 16.02.24 13:05, Hans Henrik Bergan wrote:
>>>> My name is "Hans Henrik Bergan", usually go by the nickname
>>>> "divinity76", I've contributed to OSS (including PHP) for years, and
>>>> am currently involved in 3 things that might require an RFC, and
>>>> requesting RFC karma for wiki account "divinity76".
>>>> 
>>>> 3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
>>>> 1970-01-01 00:00:00.123456 :https://github.com/php/php-src/pull/13383
>>> Actually I also want to work on this if I find time ... but as this is a BC 
>>> break I think it makes sense to revisit DateTime (and friends) to bundle BC 
>>> breaks to a single PHP version - probably PHP 9 and more sure there is a 
>>> way for users to make it work in PHP (7+)8+9.
>>> 
>>> Personal and incomplete list I think needs improvements:
>>> 
>>> * allow float for `setTimestamp`
>>> * option to return timestamp as float to simplify passing it to JS
>>> * Missing getter/setter for most of the date/time parts like 
>>> `get/setSecond`, `get/setHour` etc.
>>>    * For now I only added `get/setMicroseconds` together with 
>>> `createFromTimestamp` because 
>>> `DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)`
>>>    * After thinking about naming - I think this should be renamed to 
>>> singular 
>>> * Add missing methods to DateTimeInterface
>>> * Allow userland implements DateTimeInterface
>>>    * Define how `createFromInterface` behaves on userland implementations
>>> * fixing ISO 8601 format
>>> * fixing some return type definitions from self to static
>>> * strict mode
>>>    * `DateTime::createFromFormat('Y-m-d', '2023-02-29')`
>>>    * `DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new 
>>> DateTimeZone('Europe/Berlin'))`
>>> * Missing current microseconds on `createFromFormat` but other non defined 
>>> parts needs to be explicitly reset using `|!`
>>> * leap seconds support on UTC TZ
>>>    * As of leap seconds ... wouldn't it be better to default to +00:00 
>>> instead of UTC ?
>>> * Support nanoseconds
>>> 
>>> 
>>> I'm for sure not able to work on all these points and that's why I only 
>>> started very small close to no BC improvements without RFC.
>>> 
>> IMO, doing tweaks to this base functionality isn't the way forwards. I've 
>> been having on and off conversations with Florian over the last couple of 
>> months to see if we can design a better higher level API instead of patching 
>> the nits.
>
>Do you mean adding an additional API in C or userland? Is there a way to 
>participate on the discussion?


A bit of both, I suppose. But mainly for a user facing API. I've nothing 
concrete yet, and will soon start collecting thoughts. I'll make sure to email 
this list.

cheers
Derick

Re: [PHP-DEV] Requesting RFC karma

[Derick Rethans]

On 20 February 2024 08:41:19 GMT, Marc Bennewitz  wrote:
>Hi Hans,
>
>On 16.02.24 13:05, Hans Henrik Bergan wrote:
>> My name is "Hans Henrik Bergan", usually go by the nickname
>> "divinity76", I've contributed to OSS (including PHP) for years, and
>> am currently involved in 3 things that might require an RFC, and
>> requesting RFC karma for wiki account "divinity76".
>> 
>> 3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
>> 1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383
>
>Actually I also want to work on this if I find time ... but as this is a BC 
>break I think it makes sense to revisit DateTime (and friends) to bundle BC 
>breaks to a single PHP version - probably PHP 9 and more sure there is a way 
>for users to make it work in PHP (7+)8+9.
>
>Personal and incomplete list I think needs improvements:
>
>* allow float for `setTimestamp`
>* option to return timestamp as float to simplify passing it to JS
>* Missing getter/setter for most of the date/time parts like `get/setSecond`, 
>`get/setHour` etc.
>  * For now I only added `get/setMicroseconds` together with 
>`createFromTimestamp` because 
>`DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)`
>  * After thinking about naming - I think this should be renamed to singular 
>* Add missing methods to DateTimeInterface
>* Allow userland implements DateTimeInterface
>  * Define how `createFromInterface` behaves on userland implementations
>* fixing ISO 8601 format
>* fixing some return type definitions from self to static
>* strict mode
>  * `DateTime::createFromFormat('Y-m-d', '2023-02-29')`
>  * `DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new 
>DateTimeZone('Europe/Berlin'))`
>* Missing current microseconds on `createFromFormat` but other non defined 
>parts needs to be explicitly reset using `|!`
>* leap seconds support on UTC TZ
>  * As of leap seconds ... wouldn't it be better to default to +00:00 instead 
>of UTC ?
>* Support nanoseconds
>
>
>I'm for sure not able to work on all these points and that's why I only 
>started very small close to no BC improvements without RFC.
>
>
>Marc
>

IMO, doing tweaks to this base functionality isn't the way forwards. I've been 
having on and off conversations with Florian over the last couple of months to 
see if we can design a better higher level API instead of patching the nits.

cheers
Derick

Re: [PHP-DEV] RE: Testing new list server

[Derick Rethans]

On 18 February 2024 12:08:46 GMT, Frederik Bosch  wrote:
>
>On 18-02-2024 11:47, Derick Rethans wrote:
>> On 18 February 2024 10:23:59 GMT, Matthew Sewell  wrote:
>>> Hi,
>>> 
>>> I'm using Gmail too but with a custom domain. I did get those three
>>> messages but significantly delayed from when they were on externals.
>> That sounds about right. The queue was backed up due to rate limiting for 
>> 10+ hours. This should no longer be the case, and all messages should now 
>> have been delivered.
>> 
>> cheers
>> Derick
>> 
>> 
>>> On Sat, Feb 17, 2024 at 4:15 PM tag Knife  wrote:
>>> 
>>>> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa  wrote:
>>>> 
>>>>> Hello Derick,
>>>>> there is something wrong. I don't get all of the emails from the new
>>>>> setup, only part. Examples of emails I didn't receive:
>>>>> - https://externals.io/message/122391
>>>>> - https://externals.io/message/122390
>>>>> - https://externals.io/message/122388
>>>>> 
>>>>> I'm using Gmail and Spam doesn't contain any of them.
>>>>> 
>>>>> Kind regards,
>>>>> Jorg
>>>>> 
>>>> Same, I did not receive messages
>>>> - 122402
>>>> - 122372
>>>> - 122376
>>>> 
>>>> 
>Hi Derick,
>
>I tried to unsubscribe but I get a 550 from php-smtp4.php.net.
>
>550 5.1.1 : Recipient address
>    rejected: User unknown in local recipient table (in reply to RCPT TO
>    command)
>
>Is that also due to the new server, or is that perhaps my own mistake?
>
>Regards,
>Frederik

A bit of both. The separator changed from - to + with the server change, but 
I've only more recently updated that change in the headers that the lists add.

Cheers
Derick

Re: [PHP-DEV] RE: Testing new list server

[Derick Rethans]

On 18 February 2024 10:23:59 GMT, Matthew Sewell  wrote:
>Hi,
>
>I'm using Gmail too but with a custom domain. I did get those three
>messages but significantly delayed from when they were on externals.

That sounds about right. The queue was backed up due to rate limiting for 10+ 
hours. This should no longer be the case, and all messages should now have been 
delivered. 

cheers 
Derick 


>On Sat, Feb 17, 2024 at 4:15 PM tag Knife  wrote:
>
>>
>> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa  wrote:
>>
>>> Hello Derick,
>>> there is something wrong. I don't get all of the emails from the new
>>> setup, only part. Examples of emails I didn't receive:
>>> - https://externals.io/message/122391
>>> - https://externals.io/message/122390
>>> - https://externals.io/message/122388
>>>
>>> I'm using Gmail and Spam doesn't contain any of them.
>>>
>>> Kind regards,
>>> Jorg
>>>
>>
>> Same, I did not receive messages
>> - 122402
>> - 122372
>> - 122376
>>
>>

Re: [PHP-DEV] automatic formatting checks for pull requests?

[Derick Rethans]

On 17 February 2024 22:18:05 GMT, Ilija Tovilo  wrote:
>Hi Hans
>
>On Sat, Feb 17, 2024 at 3:31 PM Gina P. Banyard  wrote:
>>
>> On Saturday, 17 February 2024 at 11:24, Hans Henrik Bergan  
>> wrote:
>>
>> > Can we add automatic formatting checks for pull requests?
>> > Made a PR: https://github.com/php/php-src/pull/13417
>>
>> It would be nice to have some formatting rules to harmonize the codebase as 
>> it is somewhat the wild west,
>> but as far as my understanding goes is that Clang format struggles to 
>> understand our codebase (namely macros) and is difficult to set-up for 
>> php-src.
>
>Right. Consistent code style is nice, but what we have now is really
>not that bad. There are a couple things I'd want if we enforce code
>style:
>
>* Fixing the style should be easy, running a single command without
>first pushing to CI.
>* It should be fast too, so that I can easily run it for every commit,
>preferably even on-save in my editor.
>* The new code style should be applied only to newly added sections or
>changed code, not entire files. Otherwise, we'll have many changes in
>large files, with endless merge conflicts when merging up from lower
>branches.
>* The formatting tool should work for all php-src code, not just plain
>C code. We don't want to be forced to refactor old macros just because
>we need to add a single line to some long-standing code. Last time I
>tried clang-format, it utterly failed with our macros.
>
>I haven't looked at your PR in detail, so I'm not sure which of these
>points it satisfies. It would be great if you could quickly describe
>how it works, and what the goals are.
>
>Essentially, I'm just sceptical that this isn't more trouble than it's worth.
>
>Ilija

IMO, clang-format isn't really suitable. Its untunable style is often far from 
the coding style that we currently have, and it makes some really odd choices 
as to when and how to wrap lines, making code definitely less readable.

cheers
Derick

Testing new list server

[Derick Rethans]

Please don't be alarmed, we're moving the lists over to a new machine.

[PHP-DEV] Test Email — Ignore

[Derick Rethans]

(We're going to need to move the lists servers, and just trying to 
figure out how email gets currently delivered)

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

[PHP-DEV] RE: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87

[Derick Rethans]

I've added Chris (as maintainer) , and also Michael Vorisek (as writer) - he's 
worked on testing the Oracle extensions on CI. 

cheers 
Derick 

On 5 February 2024 12:54:19 GMT, Sharad Chandran R  
wrote:
>Thanks, Derick. I will create a PECL account.
>
>The GitHub username for Christopher Jones is @cjbj. Please add him to the repo 
>as well.
>
>Warm Regards,
>Sharad Chandran R, Principal Product Manager
>Oracle Database Server Technologies
>India Bangalore 
>
>
>-Original Message-
>From: Derick Rethans  
>Sent: 05 February 2024 17:05
>To: Sharad Chandran R ; s...@php.net
>Cc: internals@lists.php.net
>Subject: RE: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
>
>Hi Sharad,
>
>I've just created the new repositories for the OCI8 and PDO_OCI extensions, 
>which we have moved out of the PHP core source distribution as per a recent 
>RFC: 
>https://urldefense.com/v3/__https://wiki.php.net/rfc/unbundle_imap_pspell_oci8__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoX4aqDl8A$
> 
>
>I have invited you as a collaborator on these two new repositories:
>
>https://urldefense.com/v3/__https://github.com/php/pecl-database-pdo_oci__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoWVFsJHQg$
>https://urldefense.com/v3/__https://github.com/php/pecl-database-oci8__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoU5wk3siA$
> 
>
>I wanted to invite Christopher too (cc-ed), but I don't have his GitHub 
>username, and I can't find it anywhere.
>
>Since we moved to GitHub, the need for an VCS account also no longer exists, 
>but you might need a PECL account to release versions of this
>package: 
>https://urldefense.com/v3/__https://pecl.php.net/account-request.php__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoUjSAH4AA$
> 
>
>Christopher should know how to do this, as he's done so before for at least 
>oci8.
>
>Let me know if you have further questions.
>
>cheers,
>Derick
>
>On Mon, 5 Feb 2024, Sharad Chandran R wrote:
>
>> Hi Derick,
>> Hope you are doing well!
>> 
>> Can you let me know if my account is approved?
>> 
>> Warm Regards,
>> Sharad Chandran R, Principal Product Manager Oracle Database Server 
>> Technologies India Bangalore
>> 
>> -Original Message-
>> From: Sharad Chandran R
>> Sent: 18 January 2024 21:02
>> To: Derick Rethans ; internals@lists.php.net
>> Subject: RE: [External] : Re: [PHP-DEV] VCS Account Request: 
>> sharadchan87
>> 
>> Hi Derick,
>> Thanks for responding so quickly.
>> 
>> My GitHub account name is sharadraju.
>> 
>> Warm Regards,
>> Sharad Chandran R, Principal Product Manager Oracle Database Server 
>> Technologies India Bangalore
>> 
>> 
>> -Original Message-
>> From: Derick Rethans 
>> Sent: 18 January 2024 20:51
>> To: internals@lists.php.net; Sharad Chandran R 
>> 
>> Subject: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
>> 
>> On 18 January 2024 09:42:50 GMT, Sharad Chandran R  
>> wrote:
>> >As part of Oracle, I work with @cjones and would like to contribute to oci8 
>> >php extension.
>> >
>> 
>> Hi Sharad,
>> 
>> As you might be aware, we've recently decided to move the oci8 and Oracle 
>> extensions away from the PHP core distribution. I'm in the process of 
>> setting up a new Git repository where then work can be done, and from where 
>> releases on PECL can be made. 
>> 
>> It would probably best to wait until that's done (today / tomorrow), and 
>> then I can add you as maintainer of the repository.
>> 
>> For that, I'd need to know your GitHub account name.
>> 
>> cheers
>> Derick
>> 
>

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

[PHP-DEV] RE: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87

[Derick Rethans]

Hi Sharad,

I've just created the new repositories for the OCI8 and PDO_OCI 
extensions, which we have moved out of the PHP core source distribution 
as per a recent RFC: https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

I have invited you as a collaborator on these two new repositories:

https://github.com/php/pecl-database-pdo_oci
https://github.com/php/pecl-database-oci8

I wanted to invite Christopher too (cc-ed), but I don't have his GitHub 
username, and I can't find it anywhere.

Since we moved to GitHub, the need for an VCS account also no longer 
exists, but you might need a PECL account to release versions of this 
package: https://pecl.php.net/account-request.php

Christopher should know how to do this, as he's done so before for at 
least oci8.

Let me know if you have further questions.

cheers,
Derick

On Mon, 5 Feb 2024, Sharad Chandran R wrote:

> Hi Derick,
> Hope you are doing well!
> 
> Can you let me know if my account is approved?
> 
> Warm Regards, 
> Sharad Chandran R, Principal Product Manager
> Oracle Database Server Technologies
> India Bangalore 
> 
> -Original Message-
> From: Sharad Chandran R 
> Sent: 18 January 2024 21:02
> To: Derick Rethans ; internals@lists.php.net
> Subject: RE: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
> 
> Hi Derick,
> Thanks for responding so quickly.
> 
> My GitHub account name is sharadraju.
> 
> Warm Regards,
> Sharad Chandran R, Principal Product Manager Oracle Database Server 
> Technologies India Bangalore 
> 
> 
> -Original Message-
> From: Derick Rethans 
> Sent: 18 January 2024 20:51
> To: internals@lists.php.net; Sharad Chandran R 
> Subject: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
> 
> On 18 January 2024 09:42:50 GMT, Sharad Chandran R  
> wrote:
> >As part of Oracle, I work with @cjones and would like to contribute to oci8 
> >php extension.
> >
> 
> Hi Sharad,
> 
> As you might be aware, we've recently decided to move the oci8 and Oracle 
> extensions away from the PHP core distribution. I'm in the process of setting 
> up a new Git repository where then work can be done, and from where releases 
> on PECL can be made. 
> 
> It would probably best to wait until that's done (today / tomorrow), and then 
> I can add you as maintainer of the repository.
> 
> For that, I'd need to know your GitHub account name.
> 
> cheers
> Derick 
> 

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

On Fri, 5 Jan 2024, Derick Rethans wrote:

> I have just opened the voting on the "Policy Repository" RFC. It will 
> run until January 22nd, 2024 at 08:00 UTC:
> 
> https://wiki.php.net/rfc/policy-repository#voting_choices

Voting is now closed, and the RFC was accepted unanimously, with 28 for 
and 0 against.

I will add a link to all affected RFC's wiki pages, and other related 
pages, that the canonical version now lives in the new repository, at: 
https://github.com/php/policies

cheers,
Derick

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

Re: [PHP-DEV] VCS Account Request: sharadchan87

[Derick Rethans]

On 18 January 2024 09:42:50 GMT, Sharad Chandran R  
wrote:
>As part of Oracle, I work with @cjones and would like to contribute to oci8 
>php extension.
>

Hi Sharad,

As you might be aware, we've recently decided to move the oci8 and Oracle 
extensions away from the PHP core distribution. I'm in the process of setting 
up a new Git repository where then work can be done, and from where releases on 
PECL can be made. 

It would probably best to wait until that's done (today / tomorrow), and then I 
can add you as maintainer of the repository.

For that, I'd need to know your GitHub account name.

cheers
Derick

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

[PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

Hi,

I have just opened the voting on the "Policy Repository" RFC. It will 
run until January 22nd, 2024 at 08:00 UTC:

https://wiki.php.net/rfc/policy-repository#voting_choices

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] security email address broken?

[Derick Rethans]

On 28 December 2023 18:36:22 GMT, Robert Landers  
wrote:
>Hello internals,
>
>I sent an email to secur...@php.net (which I got from this page:
>https://wiki.php.net/security#:~:text=Please%20report%20it,security/advisories/new)
>and got back:
>
>I'm sorry to have to inform you that your message could not
>be delivered to one or more recipients. It's attached below.

It definitely arrived (as did Sebastian's). Can you tell me which ones the 
warning was for?

cheers
Derick 

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

Re: [PHP-DEV] Partitioned cookies

[Derick Rethans]

On 24 December 2023 12:46:40 CET, Niels Dossche  wrote:
>Hi internals
>
>I opened a PR [1] to implement Partitioned cookie support, as requested on the 
>bugtracker [2], into the setcookie() PHP function. This is done by adding an 
>option to the $options array, not via an additional argument to the function. 
>The amount of code to support this is tiny.
>
>This cookie option is being pushed by browser vendors (primarily by Google it 
>seems) to eliminate third-party cookies [3, 4]. One of the impacts here is 
>that cookies marked with "SameSite=None; Secured" without "Partitioned" will 
>stop working eventually during 2024.
>
>Although the Partitioned cookie proposal is still a draft, Chrome will apply 
>the change starting in January 2024 for a tiny percentage of users (as a form 
>of A/B testing it seems). Symfony has already implemented support for this 
>option as well [5].
>The SameSite option was also added in PHP when it was still in a draft.
>
>Let me know what you think and if you are okay / objecting to merging this PR.


I've two concerns (none with the PR, as I haven't checked):

- Compatibility: 
https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies#browser_compatibility
- What happens if it just stays a draft, or doesn't get accepted, or with a 
different name?

And also, would/should the PHP function enforce that this should only be set if 
for example Secure is set too? And if so, with a warning or TypeError?

cheers
Derick

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

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

On Mon, 18 Dec 2023, Jorg Sowa wrote:

> I have one question regarding the future changes. Do you see it would 
> be possible to make amendment to the accepted RFCs by the Pull 
> Requests (and formal RFC approach) making changes the existing 
> policies or adding the new policy replacing the old ones? In other 
> words, this repository would server as the collection of all ever 
> accepted policies or it would contain the unified policy 
> documentation?

It should contain the consolidated unified policy documentation that is 
"currently" active.

The other option is what we currently have, and I am proposing to go 
away from. So the idea is that this repository is not a 
collection of the accepted policy *amendments* (or *replacements*), 
as that's what the RFCs / PRs are still for.

> I'm asking because I saw the directory `archive`, and it contains 
> expired RFC. I don't think this would help new contributors. For the 
> history purposes it would be nice to have it in the git history, but 
> for the PHP development process is not relevant anymore and is little 
> overhead.

I didn't really know what to do with these documents in archive, as 
they were sortof related to the release process/timeline document. I 
suppose we don't need them, but they are not *wrong* or *outdated*. 
Simply no longer needed as the time frame has passed.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

Hi,

On Tue, 5 Dec 2023, Derick Rethans wrote:

> A while ago I started looking into all the documents (RFCs etc) that we 
> have that relate to all sort of policies. From RFCs, to who can vote, 
> naming, and security classifications as a result of a discussion with 
> the foundations folk.

A heads-up, as I posted this just over two weeks ago, and there was 
little discussion.

I am intending to open the voting on this in the next few days. With the 
intention of running it until January 5th due to the holiday season.

cheers,
Derick

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

Re: [PHP-DEV] New "PECL"

[Derick Rethans]

On Thu, 7 Dec 2023, Remi Collet wrote:

> Le 05/12/2023 à 14:45, Derick Rethans a écrit :
> > https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo
> > 
> > In this first stage, we would like to invite you in commenting on the
> > document (either inline, or here).
> 
> As inline requires a Google account...
> 
> > priority (optional): The installation "priority".
> 
> 1/ I don't like this name which is ambiguous
> 
> higher value seems to give higher priority
> which lower are loaded first
> 
> This prefix, used in various linux distro,
> is really a "load order", needed when using --enable-rtld-now
> 
> So I proprose "load order" instead

We can quibble over the name :-)

I picked something short. Debian calls it 
'priority' too in their ini files. For example:

; configuration for php common module
; priority=20
extension=calendar.so

> 2/ values
> 
> Default value can be 40 or max(requirement) + 10
> 
> In Fedora where we use this for years we have
> (IIRC debian have different practice)
> 
> 0-19 for zend_extension
>   10 for opcache
>   15 for xdebug

That's not really a good default. At least Xdebug should be 
near the end of the loading order.

> 20-39 for php-src extension
>   20 for most
>   30 if requirement (ex: pdo drivers)
> 40-99 for other (pecl...)
>   40 for igbinary, msgpack
>   50 for redis which use igbinary, msgpack

I am happy to pick a different default. I had picked what Debian seemed 
to have (20).

I don't think it matters much though, as distribitions can decide to 
change them in their binary packages regardless.

cheers,
Derick

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

Re: [PHP-DEV] New "PECL"

[Derick Rethans]

On Wed, 6 Dec 2023, Tim Starling wrote:

> On 6/12/23 00:45, Derick Rethans wrote:
> > The code is old, and hard to maintain. And the database is full of 
> > mojibake. It is also an outdated method of installing things, 
> > especially because userland code is so much easier to handle through 
> > Composer.
> 
> Thanks for working on this.
> 
> I would say that one of the reasons userland code is easier is because 
> composer packages are local and unprivileged, whereas extensions are 
> global and are typically require root to install. That problem is not 
> going to go away. For community-supplied packages we're mostly using 
> Ondrej Sury's Debian packages. For our own packages (LuaSandbox, 
> Excimer) we're building debs from git tags without reference to PECL. 
> So PECL for us is part of the release procedure just as a courtesy to 
> the downstream community.

>From what I can see, once you drop a "new-pecl.json" file (or whatever 
we'll end up calling it) into the repo at 
https://github.com/wikimedia/mediawiki-php-luasandbox it should 
automatically become compatible with the new PECL. You shouldn't have to 
deal with making actual packages and uploading them to the PECL website. 
I'm going to hope that that is an improvement for you?

> In terms of security, there should be no way to get root by uploading 
> a malicious PECL package. With debs, I'm not sure if that separation 
> is rock-solid, but at least it exists aspirationally. During build, we 
> run code from the package as non-root. During installation, as root we 
> install generated files into locations which hopefully won't be 
> executed as root. To achieve this separation with PECL, there would 
> need to be some sort of system-aware privilege separation inside the 
> PECL installer. At least it should fork and drop root privileges.

Yes, that is a good recommendation, and something that should definitely 
go into the design document.

> Signed tags only help if you trust the package developer. I don't want 
> to have to trust anyone.

That's true. I think signatures make more sense when a package is 
authored by a known organisation, such as wikimedia or MongoDB. Where 
the signatures therefore include these organisation's domain names.

> The PHP version dependency is a tricky part of the spec. When we make 
> a release, we have no way to know how forwards-compatible it is. At 
> some point, a PHP core change will break the extension. The proposed 
> structure suggests that we would have to release a new version of the 
> extension just to say that it's broken. Then later when we make a fix, 
> we would release again with that information.

I don't think you'll have to make a new *release*, as I was hoping to 
access the meta data file in the main/master branch.

I solve this for Xdebug by always setting a hard upper limit. Better 
safe than sorry.

> My motivation to maintain a historical list of supported version 
> ranges is very limited. I just want to declare, for the code I'm 
> actually releasing, the earliest supported PHP version and maybe the 
> latest confirmed PHP version.
>
> Have you considered keeping the support matrix in the registry 
> database, instead of in pecl.json? Then it can be updated with new 
> build/test information after release.

Yeah, I understand. And I feel the same. But if there is no registry (a 
goal), then there is no way to find out which of your extension version 
support a specific PHP version, without checking every tag in your 
repository. That's not going to be fast.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

On Tue, 5 Dec 2023, Larry Garfield wrote:

> On Tue, Dec 5, 2023, at 11:06 AM, Derick Rethans wrote:
> > Hi!
> >
> > A while ago I started looking into all the documents (RFCs etc) that we 
> > have that relate to all sort of policies. From RFCs, to who can vote, 
> > naming, and security classifications as a result of a discussion with 
> > the foundations folk.
> >
> > Now there was another small confusion during a recent vote, we came up 
> > with the idea to actually go forwards with this, and make all our lives 
> > easier by having one place where all these documents are located.
> >
> > Hence I have created a (beta) repository and collected that information:
> > https://github.com/php/policies
> >
> > The contents are copied verbitim from RFCs, without any editing. Some 
> > RFCs made it into a single file as IMO they belonged together.
> >
> > I have also created an RFC to establish this location, as changing 
> > policies and RFCs require an RFC:
> > https://wiki.php.net/rfc/policy-repository
> >
> > The contents are probably not exhaustive, and it is entirely possible 
> > that it does not include all information. I would therefore be greatful 
> > if you could have a look at the RFC, the collated documents, and let me 
> > know whether I missed anything, or whether you are missing something we 
> > might not even have written down yet.
> >
> > I am hoping that the discussion to establish this repository is 
> > straightforwards. Further steps will include: editing the documents so 
> > that they read as documents, and not copy-pasted content with RFC 
> > language, and including our existing coding standards.
> 
> Thank you for this, Derick!  I very much support this initiative and 
> look forward to it.
> 
> > Should the historical information in “release process” be moved out 
> > of release-process to a dedicated file?
> 
> I would say yes.  The ideal structure of the document (once edited 
> down) would be a snapshot of "how things work right now."  Historical 
> alternatives should either be just git history or a separate 
> non-normaitive set of files.

Fair enough. I also tended to go that way.

> I would also ask, does this mean future changes to process would be 
> submitted and reviewed as a PR against this repo, with the RFC for it 
> being mostly a placeholder for "vote on this PR", with explanation?  
> I would assume so, but it would be good to make that explicit.

The RFC currently has "RFCs to add or amend to policy would then target 
additions or modification of the documents in this repository, instead 
of having them just as RFC text." so that was my intention. I've updated 
the text to make this a little clearer though.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] bugs.php.net still active?

[Derick Rethans]

On Thu, 7 Dec 2023, Aleksander Machniak wrote:

> I was under impression that bugs.php.net was supposed to be phased 
> out. I.e. made read-only or something.
> 
> https://bugs.php.net/bug.php?id=78628=1 proves that it's not the 
> case and I'm receiving annoying spam recently.

It's closed for new tickets, but not for updating tickets (or adding 
comments).

cheers,
Derick

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

[PHP-DEV] New "PECL"

[Derick Rethans]

Hi there!

Within the PHP Foundation, we have been talking for a while as what to 
do with PECL, and its website.

The code is old, and hard to maintain. And the database is full of 
mojibake. It is also an outdated method of installing things, especially 
because userland code is so much easier to handle through Composer.

Through the Sovereign Tech Fund (https://www.sovereigntechfund.de/) the 
Foundation has acquired some funding to improve this situation.

Hence, to start of replacing PECL with something applicable for this 
decade, we started working on a requirements document:

https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo

In this first stage, we would like to invite you in commenting on the 
document (either inline, or here).

Please keep in mind that this is a requirements document, and should not 
contain either design or implementation details. Once we have thought 
about these details as well, this will be turned into an RFC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

Hi!

A while ago I started looking into all the documents (RFCs etc) that we 
have that relate to all sort of policies. From RFCs, to who can vote, 
naming, and security classifications as a result of a discussion with 
the foundations folk.

Now there was another small confusion during a recent vote, we came up 
with the idea to actually go forwards with this, and make all our lives 
easier by having one place where all these documents are located.

Hence I have created a (beta) repository and collected that information:
https://github.com/php/policies

The contents are copied verbitim from RFCs, without any editing. Some 
RFCs made it into a single file as IMO they belonged together.

I have also created an RFC to establish this location, as changing 
policies and RFCs require an RFC:
https://wiki.php.net/rfc/policy-repository

The contents are probably not exhaustive, and it is entirely possible 
that it does not include all information. I would therefore be greatful 
if you could have a look at the RFC, the collated documents, and let me 
know whether I missed anything, or whether you are missing something we 
might not even have written down yet.

I am hoping that the discussion to establish this repository is 
straightforwards. Further steps will include: editing the documents so 
that they read as documents, and not copy-pasted content with RFC 
language, and including our existing coding standards.


cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

[Derick Rethans]

On 3 December 2023 14:49:12 GMT, Nikita Popov  wrote:
>On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote:
>> Hi all,
>> 
>> I've just opened voting for the final anonymous classes RFC @ 
>> https://wiki.php.net/rfc/final_anonymous_classes.
>> 
>> Voting started now, and will run until December 18th 2023, 00:00 GMT.
>
>For the record, I've voted against this proposal because I believe it should 
>have gone with option 2, that is to *always* make anonymous classes final.
>
>It makes very little sense to me that everyone needs to explicitly mark their 
>anonymous classes as final just because there is a class_alias loophole that 
>could, in theory, have been used to extend anonymous classes in the past. 
>Especially given that there is no evidence of this "feature" being used in the 
>wild (or if there is such evidence, it was not presented in the proposal).
>
>Regards,
>Nikita
I agree with this, and would also say that this RFC is the most thin one I've 
seen.

There is no reasoning, or examples, or pretty much anything else in it. 

cheers
Derick

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

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

[Derick Rethans]

On 24 November 2023 00:31:16 GMT, Saki Takamachi  wrote:
>Hi internals,
>
>I started voting on my RFC "Change the edge case of round()”.
>
>Voting will end December 8th, 00:00 GMT.
>
>https://wiki.php.net/rfc/change_the_edge_case_of_round
>
>Regards.
>
>Saki
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php

I've voted no, but only because I think that because this is technically a 
documented (through RFC) BC break, it should wait for PHP 9, and not for any 
8.*.

cheers
Derick

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

Re: [PHP-DEV] Reproducible Builds

[Derick Rethans]

On 29 November 2023 00:48:28 GMT, Matthew Weier O'Phinney 
 wrote:
>On Tue, Nov 28, 2023, 5:28 PM Derick Rethans  wrote:
>
>> On 28 November 2023 17:28:18 GMT, Sebastian Bergmann 
>> wrote:
>>
>> >While we could probably replace __DATE__ and __TIME__ with
>> SOURCE_DATE_EPOCH [3] [4], I cannot help but wonder whether having the date
>> and time when the executable was built in the executable is actually
>> useful. How attached are we to having the date and time of the build in the
>> output of phpinfo(), "php -i", etc.?
>>
>> It is really useful for the development versions of PHP. Knowing whether
>> your are running a PHP-dev from last week or last month is important.
>
>
>Would Marco's suggestion of using a git hash solve that? You'd then get
>both a reproducible build AND know when/what it was generated from.
>
>>
>>
>>
>>

Not really, as a hash doesn't directly tell me the date/time, and neither would 
it help in dev branches / checkouts where the latest changes haven't been 
comiited yet.

cheers
Derick

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

Re: [PHP-DEV] Reproducible Builds

[Derick Rethans]

On 28 November 2023 17:28:18 GMT, Sebastian Bergmann  wrote:

>While we could probably replace __DATE__ and __TIME__ with SOURCE_DATE_EPOCH 
>[3] [4], I cannot help but wonder whether having the date and time when the 
>executable was built in the executable is actually useful. How attached are we 
>to having the date and time of the build in the output of phpinfo(), "php -i", 
>etc.?

It is really useful for the development versions of PHP. Knowing whether your 
are running a PHP-dev from last week or last month is important. 

For released versions, not so much. 

cheers
Derick 

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

Re: [PHP-DEV] Debian Upgrade

[Derick Rethans]

On Mon, 20 Nov 2023, Derick Rethans wrote:

> On 20 November 2023 21:37:55 GMT, Rowan Tommins  
> wrote:
> >On 15/11/2023 16:59, Derick Rethans wrote:
> >> In the last few days, I have upgrade all our Digital Ocean droplets from
> >> Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.
> >
> >Thanks for getting things current! System maintenance is such an 
> >essential but often underappreciated task.
> >
> >I notice news.php.net (and therefore externals.io, which feeds from 
> >it) hasn't copied any message from the list since the day after you 
> >posted this (last timestamp is 16 Nov 2023 22:14:19 -). Could 
> >that be related somehow?
> >
> >Or if it's just coincidence, maybe you or someone else here knows 
> >which service might need prodding to bring it back to life?
> 
> Yes, this could be related. Somebody on the foundation slack raised it 
> too, so I'll have a look ASAP.

I have fixed this now.

It turned out to be a bug in *bugs.php.net*, which I had fixed 
yesterday:
https://github.com/php/web-bugs/commit/9ed00f752fb1f82a93ed08a13f45219e5723c0d0

Without this fix, emails sent to the bugs (and docs-bugs) mailinglists 
had very long "From" addresses.

Colobus, the tool that parses the mailinglists and creates the news 
interface and NNTP server, had a MySQL column defined for this to 
varchar(255). Usually enough, but it was now bailing out.

The "fix" was to change that column to "text" — not pretty, but better 
than hacking the mailinglist software's index.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Debian Upgrade

[Derick Rethans]

On 20 November 2023 21:37:55 GMT, Rowan Tommins  wrote:
>On 15/11/2023 16:59, Derick Rethans wrote:
>> In the last few days, I have upgrade all our Digital Ocean droplets from
>> Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.
>
>
>Hi Derick,
>
>Thanks for getting things current! System maintenance is such an essential but 
>often underappreciated task.
>
>I notice news.php.net (and therefore externals.io, which feeds from it) hasn't 
>copied any message from the list since the day after you posted this (last 
>timestamp is 16 Nov 2023 22:14:19 -). Could that be related somehow?
>
>Or if it's just coincidence, maybe you or someone else here knows which 
>service might need prodding to bring it back to life?
>
>Regards,
>

Yes, this could be related. Somebody on the foundation slack raised it too, so 
I'll have a look ASAP.

cheers
Derick

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

Re: [PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

[Derick Rethans]

On Wed, 1 Nov 2023, Derick Rethans wrote:

> I have just opened voting on the RFC to unbundle imap, pspell, and 
> oracle integrations.
> 
> Each extension can be voted on separately. Voting started now, and 
> will run until November 15th, 24:00 GMT.
> 
> Link: https://wiki.php.net/rfc/unbundle_imap_pspell_oci8#voting

Voting is now closed, with unbundling imap and pspell passing 
unanimously (27:0) and unbundling oracle integrations passing with 
(26:1).

I will soon start making PRs to implement this result.

cheers,
Derick

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

[PHP-DEV] Debian Upgrade

[Derick Rethans]

Hi!

In the last few days, I have upgrade all our Digital Ocean droplets from 
Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.

I have not encountered any problems, but if you do, please let me know!

cheers,
Derick

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

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[Derick Rethans]

On 12 November 2023 16:47:37 GMT, "Máté Kocsis"  wrote:
>Hi Internals,
>
>Following my straw poll about the Process resource name, I would like to
>present an RFC which clarifies the rough timeline and the BC promises of
>the "resource to object conversion" project.
>
>Link: https://wiki.php.net/rfc/resource_to_object_conversion
>
>I'm looking forward to your feedback!




I don't really have any comments beyond that everything stream related should 
happen at the same time.

I think I would prefer ProcessHandle and all streams related change to happen 
with 9.0.

As to COM, I dont think many people at going to notice this, as I doubt it'd be 
in much use.

Did you do an analyses as to how much either of these changes could break 
anything?

cheers
Derick

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