Given that 3.9.23 will be the first version eith explizit PHP8 support i would recommend to do any change we want to do now.

Just to avoid any confusion for extension devs. This does not affect any of your extension code yet. Named arguments are opt-in and renaming arguments are only being an issue once named arguments are live. So renaming them now woth the first version that supports PHP8 is fine in my opinion as this is the first version you could build your PHP8 only extension on.

The only very rare case of issue would be that you already have a PHP8 only extension on 3.x that ises named arguments and we are changing just that argument that you where used in your extension. But given no release has benn officially tagged for PHP8 yet and the masshosters do not have PHP8 yet i would say it would be a fair change now to make the future usage consitent.

Cc @HLeithner @wilsonge

I'm in favor for fixing our argument naming but don't think that we should give a b/c promise on named arguments till j4 or later

Making the changes as soon as possible is the wise thing to do. Specially since PHP 8 is due November 26, 2020.

Being first time in the front row of implementing new programming language changes of PHP 8 would actually surprise me to see in Joomla, so I'm definitely in favor to see it happen.

I would say after sharing this within all groups and only getting positive feedback I would say we can go for a set of PRs to change the arguments as susggested. @SharkyKZ

This kind of change should be merged for this exact reason.

#29812

No that's not the same or better it's the same because now we have no b/c break for php 8 but for #29812 we would add a b/c break if we did it wrong.

Or better that PR should be send against staging so we can include it in the first release that supports PHP8

sorry my fault I thought the #29812 changes array keys but it doesn't so it should be ok

sorry my fault I thought the #29812 changes array keys but it doesn't so it should be ok

So it should be done against staging right? As when it comes with 4.x it would be a b/c break right?

"Rename some function arguments in preparation for PHP 8" = exactly what #29812 does at the same time as fixing a decade old typo.

Or better that PR should be send against staging so we can include it in the first release that supports PHP8

Well considering some files in #29812 don't even exist in Joomla 3 I don't see how that would be possible :) - it would need splitting in two. Plus the lack of interest in #29812 already shows that getting it past the post might be hard :)

Well considering some files in #29812 don't even exist in Joomla 3 I don't see how that would be possible :)

Well than they still can be patched with 4.x as this is new API == no B/C break. But the existing ones have to be changed in 3.x before the first official PHP8 supported version.

Plus the lack of interest in #29812 already shows that getting it past the post might be hard :)

Well you know how fast it can go. ;) In this case as this has to be done before the next 3.x release I think we find testers for that too.

PR for libraries/src directory #31148.

Can I also refer you to the Database column names which has a camelCase / snake_case issue

joomla/coding-standards#269

"That is assuming we do want to add this feature to our B/C promise."

Cross posting #31424 for interest.

@SharkyKZ are we finished with this issue and can we close it?

I expect that is done, thank you very much @SharkyKZ for creating the PRs