Why the Extended Coding Style Guide is its own PSR
60 views
Skip to first unread message
Korvin Szanto
unread,
Aug 24, 2015, 1:25:21 PM8/24/15
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Sign in to report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to php...@googlegroups.com
This is partly directed at Cal, moved discussion here to keep it out of the voting thread.
The PSR workflow guidelines are pretty clear when it comes to errata that they cannot contain "new rules"[1], that leaves us with a new short PSR being our only option to extends PSR-2. I'm happy to discuss a new method of extending old PSR's in a way that doesn't change the requirements of existing implementations.
You do not have permission to delete messages in this group
Copy link
Report message
Sign in to report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to php...@googlegroups.com
An example which springs to mind is the IETF "STD" series,
complementary of the better-known "RFC" series. RFCs are immutable,
errata included, while STDs are essentially pointers to the most
current RFC on an important topic (e.g. STD 13 = RFC 1034 + RFC 1035).
You do not have permission to delete messages in this group
Copy link
Report message
Sign in to report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to FIG, PHP
Indeed. Initially I shared a similar view with Cal that it would appear to be a bit small to be worthy of a whole PSR but after an IRC discussion in #phpfig I realised:
1) There was more to cover than I'd initially thought of.
2) It doesn't really matter how small a PSR is. PSR-9 for example is going to be relatively small and PSR-0/PSR-4 are both very small (but extremely important).
The idea here would be that a project can simply edit it's docs to say 'PSR-12' instead of 'PSR-2' (1 character difference) if they are updating their minimum requirement to a higher php version and taking advantage of new functionality. It requires no changes to behaviour of existing projects, so it doesn't matter how large or small the PSR is as it just added some extra points to PSR-2 and if projects choose they can modify in their docs to specify this PSR if they want those extra guidelines.