Proposal: Coding standards extension PSR to reflect new functionality

[Michael Cullum (phpBB)]

Hi all,

So this has come up on IRC a few times now and more recently it was highlighted on the mailing list here[1].
PSR-2 was accepted in 2012 and since then a number of changes have been made to PHP, most notably recently
in PHP 7 which have an effect on coding style. What is being proposed is a new PSR that extends PSR-2 (As
PSR-2 extends PSR-1) which includes additional details of how formatting should be done.

One of the most obvious things to include is return type declarations but it should/could also be extended
to include other changes such as anonymous classes (as we have closures in PSR-2) and uniform variable syntax
(if anyone has any suggestions for other new functionality introduced since 5.4 (not including 5.4) then this
can be discussed in draft).

We could also include the PSR-2 errata in this PSR as errata are non-binding if this is generally supported.

This is not a suggestion of a PSR to use in favour of PSR-2 as PSR-4 was, but an extension which provides
additional styling guidelines, in line with what is in PSR-2, and inclusion of a statement that says that
PSR-2 must be followed for alignment with the new PSR (and therefore by extension PSR-1 also).

Speed is partly of the essence in this as it would be good to get it out before PHP 7.0 is stable so that
people can begin using the PSR terms when they start writing PHP 7 code, as opposed to having people adapt
later on, but that's not saying that this should not be done correctly and with care. It should be quite
a small lightweight PSR also as it's just extending on PSR-2 with PSR-2 errata (already agreed) and changes
related to new functionality which will be kept inline with how formatting is generally dictated in PSR-2
already.

[1]: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/php-fig/wh9avopSR9k

--

Thanks,

Michael Cullum

phpBB

[Korvin Szanto]

+1

I'm happy to sponsor or coordinate now that my work is pretty much done with the stormpath vote.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ee696457-73dd-4921-9407-b57f11ff575e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul M. Jones]

> On Aug 21, 2015, at 16:04, Michael Cullum (phpBB) <m...@michaelcullum.com> wrote:
>
> Speed is partly of the essence in this as it would be good to get it out before PHP 7.0 is stable so that
> people can begin using the PSR terms when they start writing PHP 7 code, as opposed to having people adapt
> later on, but that's not saying that this should not be done correctly and with care. It should be quite
> a small lightweight PSR also as it's just extending on PSR-2 with PSR-2 errata (already agreed) and changes
> related to new functionality which will be kept inline with how formatting is generally dictated in PSR-2
> already.

(For those not familiar with the history of PSR-1 and PSR-2, I was the one who shepherded them through writing and acceptance process after a initial suggestion by Klaus Silveira.)

My opinion is to wait and see. One of the positive aspects of PSR-1 and 2, to me anyway, was that they were a recognition of common practice, and as such were primarily *de*scriptive instead of *pre*scriptive. I think taking a similar approach here would be wise: review what the member projects do, and revisit this after a significant number of them have come up with a practice.


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

[Michael Cullum]

The problem with waiting and seeing is that then people have started to differ, which was one of the main problems with PSR-2 adoption (people already did different things and didn't want to switch just to conform with the PSR) and a lot of projects today still don't use it for that reason. Also, in some aspects I think standards are already established from rough interpretation of spacing etc. from PSR-2 and from RFC examples (Most PHP7 code I've seen is pretty similarly written already).

It will also be quite a long time before a large enough sample of FIG projects to sample would be using PSR-7 code (Although I guess GoPHP7 might help this).

--

Michael Cullum

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0D8FB269-E8FC-44C0-8E01-4F526B94E6DB%40gmail.com.

[Korvin Szanto]

On Fri, Aug 21, 2015 at 2:17 PM Paul M. Jones <pmjo...@gmail.com> wrote:

> On Aug 21, 2015, at 16:04, Michael Cullum (phpBB) <m...@michaelcullum.com> wrote:
>
> Speed is partly of the essence in this as it would be good to get it out before PHP 7.0 is stable so that
> people can begin using the PSR terms when they start writing PHP 7 code, as opposed to having people adapt
> later on, but that's not saying that this should not be done correctly and with care. It should be quite
> a small lightweight PSR also as it's just extending on PSR-2 with PSR-2 errata (already agreed) and changes
> related to new functionality which will be kept inline with how formatting is generally dictated in PSR-2
> already.

(For those not familiar with the history of PSR-1 and PSR-2, I was the one who shepherded them through writing and acceptance process after a initial suggestion by Klaus Silveira.)

My opinion is to wait and see. One of the positive aspects of PSR-1 and 2, to me anyway, was that they were a recognition of common practice,  and as such were primarily *de*scriptive instead of *pre*scriptive.  I think taking a similar approach here would be wise: review what the member projects do, and revisit this after a significant number of them have come up with a practice.

I agree that it would be ideal to have some sort of real world sample, but I think that as a group we have good enough representation to come up with a solid draft to vote on. Worst case scenario is that the draft doesn't pass and we end up stalling with a reserved PSR number until there are adequate real world examples to satisfy the group.

[Hari K T]

Before people starting to write and preferring their own style will be good we have one.

Else every framework will write their own style guides and it may be hard to impress them. As almost every framework is representing here and as other people can always suggest for this is an open group , this is a nice thing to do before PHP 7 is out.

Hari K T

You can ring me : +91 9388 75 8821

http://harikt.com , https://github.com/harikt , http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT

Skype  : kthari85

Twitter : harikt

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWWVZvJ5L4hTJDxniyOQT0LD5MiRhsgvhSFmr_LwO3bj8Q%40mail.gmail.com.

[Alexander Makarov]

I'm definitely in favor of it. Can help with reviews, additions, collecting huge Yii community opinions.

[Moshe Brevda]

Im with Hari on this. Getting something in place BEFORE habits become set is probably the smoother way to standardization.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b1f748da-4c81-4115-88af-a95c1ac919ff%40googlegroups.com.

[Stefano Torresi]

Hey all,

Just for the record, I remind you the presence of these notes:
https://github.com/php-fig/fig-standards/wiki/Further-Style-Guide-Considerations

They should definitely be included/discussed in the new proposal.

[Michael Cullum]

One of those was on my mental list (finally block) but the others we can certainly consider in the draft phase as we are errata but we'd want to ensure we aren't breaking any projects using PSR-2.

--

Michael C

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1sXLd5Ufpf5N%3DXmbhWBHdM4K7YbBFTEg0d-XEy6Tomvpg%40mail.gmail.com.