-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
added the finally
block.
#321
Conversation
I don't think new things can be added to a standard once it's been accepted. Only typo fixes and such. |
I believe @GrahamCampbell is correct. From what I've seen on the Google group when proposed changes are submitted to formally accepted PSRs, there is near-unanimous agreement that changes won't be made. Take this recent example thread about changing how PSR-2 formats Once a proposed PSR is accepted, it's cemented. It represents the standard recommendation of the group at that point in time, and includes recommendations only for PHP features that existed at the time of acceptance. Changing it after the fact would mean that a project that had followed the recommendation would no longer be in line with the PSR, making the whole point of the standard meaningless. In order to make "additions" to the PSR, a proposal for a new PSR would have to be submitted and put through the approval process. For example, at the time that PSR-0 was accepted in 2009, PHP 5.2 was the latest stable release. So, features that were introduced in 5.3 such as formal namespaces are not included in PSR-0, because they simply didn't exist in practice. In order to "amend" PSR-0 to include autoloading recommendations for namespaces, PSR-4 was proposed and formally accepted. Now, projects can choose to adhere to PSR-0 only, to PSR-4 only, to both PSR-0 and PSR-4, or to neither. Their state of adherence will then never change, because those PSRs will not change. So, in the same way, @rafreis, maybe you could investigate the possibility of putting together a new PSR proposal that would "extend" PSR-2 to include recommendations for newer language features such as |
@danapplegate I'd support such a proposal. |
@danapplegate You include some historical inaccuracies in your narrative.
PSR-0 does include formal namespaces. It additionally makes allowance for underscores as pseudo-namespace separators.
No, PSR-4 was introduced primarily to collapse the directory hierarchy of the class-to-name conventions; it secondarily removes the allowance for underscores as pseudo-namespace separators. |
I Agree, but as it is a minimal change I believe that will be better wait the PHP 5.6 be stable to do a new propose PSR, so will have more changes. What do you think "@ everyone" ? |
@rafreis it is stable http://php.net/archive/2014.php#id2014-08-28-1 |
Nice, then... Someone know how to propose a new PSR? |
Check https://github.com/php-fig/fig-standards/blob/master/bylaws/004-psr-workflow.md. Then create a pull request with new PSR and post it to https://groups.google.com/forum/#!forum/php-fig (check for already made proposals there). |
Okay, thanks @samdark |
Ah, yes of course, thank you for the clarifications, @pmjones! |
So this definitely cannot be added to the existing PSR, but could be added to a future PSR-2 replacement. I have had one floating around in mind for a while and one day I'll get to it, when other more important things have been taken care of. My list of considerations for the replacement can be found here: https://github.com/php-fig/fig-standards/wiki/Further-Style-Guide-Considerations Get in touch if you want to take this new PSR on yourself, but we can't merge this for sure. |
No description provided.