Fwd: [PSR-12] Review phase review
99 views
Skip to first unread message
Larry Garfield
Feb 13, 2018, 11:56:42 AM2/13/18
to php...@googlegroups.com
As discussed, these were my comments on PSR-12. I don't recall seeing any
movement on addressing them.
The full review thread with comments from others is at:
https://groups.google.com/forum/?#!msg/php-fig/vZOpga3xoLg/7gdNxNlVCQAJ
--Larry Garfield
---------- Forwarded Message ----------
Subject: [PSR-12] Review phase review
Date: Sunday, December 10, 2017, 3:00:40 PM CST
From: Larry Garfield <la...@garfieldtech.com>
To: php...@googlegroups.com
*Puts on CC member hat*
4.2:
* Regarding trait whitespacing, it feels incomplete. Like, class bodies
should get the same "set of blocks with one line separating them" treatment as
the file header does. That would effectively expand to one line between
methods, and between the properties, too. I don't know if that's scope creep
but as is it feels lacking and incomplete.
* Related: Technically I see nothing that mandates properties-first, then
methods. That's virtually universal from what I've seen, though. Should that
be included in class organization?
4.5:
* I still hold that "function foo(): string" is silly and the colon should
have spaces on either side. This feels like an entirely unnecessary
inconsistency.
8:
* I know it's unresolvable without breaking the most controversial part of
PSR-2, but I am just going to call out the inconsistency in anonymous classes
between closures and explicit classes. That's messy.
Metadoc:
2:
* "PHP-FIG" is usually hyphenated, although Secretaries, please decide on
which the proper spelling is. :-)
* "we have taken a more prescriptive approach and defined the standards for new
language features as they are released" - eh, I know that was the intent, but
is that still true, given how long PSR-12 has been in progress?
* " it will have a better chance of being adopted but this is in the hope that
it will mean that projects." - That sentence is grammatically incomprehensible
and ends in the middle so I have no idea what it's saying.
3.1:
* PHP 7.1 and 7.2 should be mentioned, since there is mention of 7.1 syntax.
(I don't know that 7.2 has any new syntax we should care about.)
4.4:
* The description here of the vote, IIRC, is rather misleading. It wasn't a
"do you like this", but a "do you have a really really good reason to not do
it the way we've already written?" That's why the votes are so dramatically
biased in favor of the status quo: The survey specifically said to bias that
direction. The survey should be accurately described or omitted. As is, it
is misleading and false.
4.5:
* Typo, there's an extra ] in the text.
6:
* No need to bold names. I don't think any other specs do.
7:
* Formatting error on "Entrance Vote".
Generally:
* notice there's no mention of variadics. Was that deliberate? If the goal
is to cover "language features that didn't exist in 5.3 when PSR-2 was
written", variadics and the splat operator (which is still the coolest named
operator ever) seem like something that should be covered.
--
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/4025631.r995PC85BO%40vulcan.
For more options, visit https://groups.google.com/d/optout.
-----------------------------------------
movement on addressing them.
The full review thread with comments from others is at:
https://groups.google.com/forum/?#!msg/php-fig/vZOpga3xoLg/7gdNxNlVCQAJ
--Larry Garfield
---------- Forwarded Message ----------
Subject: [PSR-12] Review phase review
Date: Sunday, December 10, 2017, 3:00:40 PM CST
From: Larry Garfield <la...@garfieldtech.com>
To: php...@googlegroups.com
*Puts on CC member hat*
4.2:
* Regarding trait whitespacing, it feels incomplete. Like, class bodies
should get the same "set of blocks with one line separating them" treatment as
the file header does. That would effectively expand to one line between
methods, and between the properties, too. I don't know if that's scope creep
but as is it feels lacking and incomplete.
* Related: Technically I see nothing that mandates properties-first, then
methods. That's virtually universal from what I've seen, though. Should that
be included in class organization?
4.5:
* I still hold that "function foo(): string" is silly and the colon should
have spaces on either side. This feels like an entirely unnecessary
inconsistency.
8:
* I know it's unresolvable without breaking the most controversial part of
PSR-2, but I am just going to call out the inconsistency in anonymous classes
between closures and explicit classes. That's messy.
Metadoc:
2:
* "PHP-FIG" is usually hyphenated, although Secretaries, please decide on
which the proper spelling is. :-)
* "we have taken a more prescriptive approach and defined the standards for new
language features as they are released" - eh, I know that was the intent, but
is that still true, given how long PSR-12 has been in progress?
* " it will have a better chance of being adopted but this is in the hope that
it will mean that projects." - That sentence is grammatically incomprehensible
and ends in the middle so I have no idea what it's saying.
3.1:
* PHP 7.1 and 7.2 should be mentioned, since there is mention of 7.1 syntax.
(I don't know that 7.2 has any new syntax we should care about.)
4.4:
* The description here of the vote, IIRC, is rather misleading. It wasn't a
"do you like this", but a "do you have a really really good reason to not do
it the way we've already written?" That's why the votes are so dramatically
biased in favor of the status quo: The survey specifically said to bias that
direction. The survey should be accurately described or omitted. As is, it
is misleading and false.
4.5:
* Typo, there's an extra ] in the text.
6:
* No need to bold names. I don't think any other specs do.
7:
* Formatting error on "Entrance Vote".
Generally:
* notice there's no mention of variadics. Was that deliberate? If the goal
is to cover "language features that didn't exist in 5.3 when PSR-2 was
written", variadics and the splat operator (which is still the coolest named
operator ever) seem like something that should be covered.
--
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/4025631.r995PC85BO%40vulcan.
For more options, visit https://groups.google.com/d/optout.
-----------------------------------------
Joe T.
Feb 14, 2018, 2:18:26 AM2/14/18
to PHP Framework Interoperability Group
This may be a thread of discussion meant for committee discussion only, but 12 happens to be an aspect of code - PHP in particular - that matters a lot to me. As such, here are my thoughts about the points raised... Please forgive any lines i'm crossing (but let me know, so i can play better with others)...
4.2:
4.2:
* Related: Technically I see nothing that mandates properties-first, then
methods. That's virtually universal from what I've seen, though. Should that
be included in class organization?
Yes please! i would also support a formalized accessibility structure, but i'll settle for requiring constants-properties-methods in that order.
4.5:
* I still hold that "function foo(): string" is silly and the colon should
have spaces on either side. This feels like an entirely unnecessary
inconsistency.
Consistency over status quo. Always (also applies to note about part 8). i would extend that same ideal to braces on ALL structures, but i know that will go nowhere... ;-)
8:
Correction needed: Usage of "parenthesis" should be "brace".
General
A decent IDE gives a lot more formatting control than the standard describes. i understand the intention is to provide a baseline without being too meticulous, but maybe it would be worth examining some of the formatting controls available from leading IDEs and see if some perceived gaps in the document could be filled in? Also, maybe some increased specificity would be useful. i generally believe less ambiguity, the better the results.
Meta
i've never liked the survey origin of the standards. Exactly as Larry describes, it always struck me as, "What's the current majority pattern?" Seems it would have been better to establish a unified, consistent standard, and look for discussion around, "What justification is there not to do it this way?" As a result, the standard has gaps, inconsistencies, and patterns that might not actually benefit readability ...just because. Preaching aside, i agree the survey's purpose and origin should be more accurate. i don't favor omitting it, because it establishes the origin, for better or worse. Someone who comes to this standard deserves to know its origin, and decide whether they prefer "standards" based on majority vote status quo, or want to go a different direction. If the standard evolves and the survey is no longer a major contributing factor to its current/future state, then sure, remove it.
Okay then, back to you guys. Again, apologies if toes were stepped on.
-Joe T.
8:
Correction needed: Usage of "parenthesis" should be "brace".
General
A decent IDE gives a lot more formatting control than the standard describes. i understand the intention is to provide a baseline without being too meticulous, but maybe it would be worth examining some of the formatting controls available from leading IDEs and see if some perceived gaps in the document could be filled in? Also, maybe some increased specificity would be useful. i generally believe less ambiguity, the better the results.
Meta
i've never liked the survey origin of the standards. Exactly as Larry describes, it always struck me as, "What's the current majority pattern?" Seems it would have been better to establish a unified, consistent standard, and look for discussion around, "What justification is there not to do it this way?" As a result, the standard has gaps, inconsistencies, and patterns that might not actually benefit readability ...just because. Preaching aside, i agree the survey's purpose and origin should be more accurate. i don't favor omitting it, because it establishes the origin, for better or worse. Someone who comes to this standard deserves to know its origin, and decide whether they prefer "standards" based on majority vote status quo, or want to go a different direction. If the standard evolves and the survey is no longer a major contributing factor to its current/future state, then sure, remove it.
Okay then, back to you guys. Again, apologies if toes were stepped on.
-Joe T.
Adrien Crivelli
Feb 14, 2018, 10:07:18 PM2/14/18
to PHP Framework Interoperability Group
better to establish a unified, consistent standard
I couldn't agree more with you on that. I am very disappointed at inconsistencies that will be introduced and/or kept, such as the declare assignment operator, and the braces situation since PSR-2. It makes the standard harder to explain, memorize and apply for very little gain (or arguably no gain at all).
Reply all
Reply to author
Forward
0 new messages