-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Rename some function arguments in preparation for PHP 8 #30988
Comments
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. |
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 comment was marked as abuse.
This comment was marked as abuse.
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 |
So it should be done against staging right? As when it comes with 4.x it would be a b/c break right? |
This comment was marked as abuse.
This comment was marked as abuse.
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.
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 |
Can I also refer you to the Database column names which has a |
This comment was marked as abuse.
This comment was marked as abuse.
@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 |
Problem identified
With the introduction of named arguments in PHP 8, changing function argument names becomes a B/C break. Until PHP 8 is released, we can update existing function signature with new argument names.
Proposed solution
We should convert existing snake_case arguments to camelCase to better follow our coding standards.
We should review other arguments and rename them if they are unclear or inaccurate.
If not done before PHP 8 is released, the next opportunity would be the next major Joomla! version. That is assuming we do want to add this feature to our B/C promise.
Open questions
Should this be done against staging or 4.0?
The text was updated successfully, but these errors were encountered: