Explaining my PSR-12 vote
412 views
Skip to first unread message
Larry Garfield
Aug 9, 2019, 5:22:12 PM8/9/19
to PHP-FIG
(Putting this in a separate thread to keep the voting thread clean.)
I have a number of issues with this spec as written, which I have grouped into 3 sets:
Smaller issues:
* 3.2 Non-Goals, this section is a run-on sentence. (This is a safe change to make post-vote even if it passes.)
* There's an inconsistency between where a a style is defined in English and then an example provided, but then in some cases only a example is provided and the prose just says "like this". Usually it's clear enough what is intended, but there seems little rhyme or reason for that inconsistency. See 4.2's last example, for an example, or 5.3 (while), or 5.6.
* In section 5, it's stated that booleans in a conditional statement if multi-lined should be at the beginning or end of the line, not a mix of both. (This is new in PSR-12, it looks like.) Why is it not specified which? That seems like the sort of thing that a spec of this sort should be concerned with. (Anecdotally, start of line seems more common and easier to read.)
Medium issues:
* As previously discussed, the colon position for return types is very inconsistent, as nearly everything else requires a space on either side of a sigil and thus it becomes less readable. It's only "consistent" with the practice that people picked up from early PSR-12 drafts that said to do so, becoming a self-fulfilling prophesy that was never corrected.
* 6.1, unariy operators, inc/dec must not have spaces, and casting must not have a space inside the parens. OK fine. The example, however, has a space between the parentheses and the variable. Is that a requirement, and thus inconsistent with the other unary operator? That's unclear, because the text doesn't say.
Larger issue:
* The major objection, and the one that decides my vote from a process standpoint, is in the metadoc. Specifically section 4.4. The metadoc says
"In order to settle things using data, survey was conducted and responses from 142 people including 17 project representatives were gathered:"
implying that decisions were "put to a vote" as it were, and overwhelmingly were subjectively in favor of the specific decisions that were made.
That is an incorrect and misleading description of events.
First, no date or source is given for the survey. It's not clear if it was made before anything was written or long after. The correct answer is, I believe, "somewhere in the middle", but it is now several years old. (It predated FIG v3, I believe.)
Additionally, the survey in question did not ask people for their opinion. It asked "can you accept this" and "do you have any non-subjective objections". That is, the survey very deliberately biased participants to accept the proposals presented, not to express their specific opinion. That is not at all how it is presented in the metadoc, which I believe is negligent.
Further, the content of the survey did not, as I recall, present why the recommendations made at that time were being made. That is, given that some decisions had open disagreement, a survey was put forward that actively and deliberately biased participants toward one particular answer and then was used as justification for supporting that answer, because the survey said so. That is disingenous, and for the survey to be presented without any of that context as it is here only compounds the disingenuity.
Per bylaws, "The Core Committee is responsible for ensuring a high level of quality and consistency amongst all published specifications, and that all relevant perspectives and use cases are given due consideration."
I do not believe that this spec in its current form gives "all relevant perspectives... due consideration", and in fact misrepresents some perspectives. Nor do I see any justification in the metadoc for the inconsistencies noted above.
I appreciate the time and effort that many people have put into PSR-12 during its long run, and I want to be clear that I bear them no ill will, but in its current form I do not believe this specification is complete nor has process been properly followed.
--
Larry Garfield
la...@garfieldtech.com
I have a number of issues with this spec as written, which I have grouped into 3 sets:
Smaller issues:
* 3.2 Non-Goals, this section is a run-on sentence. (This is a safe change to make post-vote even if it passes.)
* There's an inconsistency between where a a style is defined in English and then an example provided, but then in some cases only a example is provided and the prose just says "like this". Usually it's clear enough what is intended, but there seems little rhyme or reason for that inconsistency. See 4.2's last example, for an example, or 5.3 (while), or 5.6.
* In section 5, it's stated that booleans in a conditional statement if multi-lined should be at the beginning or end of the line, not a mix of both. (This is new in PSR-12, it looks like.) Why is it not specified which? That seems like the sort of thing that a spec of this sort should be concerned with. (Anecdotally, start of line seems more common and easier to read.)
Medium issues:
* As previously discussed, the colon position for return types is very inconsistent, as nearly everything else requires a space on either side of a sigil and thus it becomes less readable. It's only "consistent" with the practice that people picked up from early PSR-12 drafts that said to do so, becoming a self-fulfilling prophesy that was never corrected.
* 6.1, unariy operators, inc/dec must not have spaces, and casting must not have a space inside the parens. OK fine. The example, however, has a space between the parentheses and the variable. Is that a requirement, and thus inconsistent with the other unary operator? That's unclear, because the text doesn't say.
Larger issue:
* The major objection, and the one that decides my vote from a process standpoint, is in the metadoc. Specifically section 4.4. The metadoc says
"In order to settle things using data, survey was conducted and responses from 142 people including 17 project representatives were gathered:"
implying that decisions were "put to a vote" as it were, and overwhelmingly were subjectively in favor of the specific decisions that were made.
That is an incorrect and misleading description of events.
First, no date or source is given for the survey. It's not clear if it was made before anything was written or long after. The correct answer is, I believe, "somewhere in the middle", but it is now several years old. (It predated FIG v3, I believe.)
Additionally, the survey in question did not ask people for their opinion. It asked "can you accept this" and "do you have any non-subjective objections". That is, the survey very deliberately biased participants to accept the proposals presented, not to express their specific opinion. That is not at all how it is presented in the metadoc, which I believe is negligent.
Further, the content of the survey did not, as I recall, present why the recommendations made at that time were being made. That is, given that some decisions had open disagreement, a survey was put forward that actively and deliberately biased participants toward one particular answer and then was used as justification for supporting that answer, because the survey said so. That is disingenous, and for the survey to be presented without any of that context as it is here only compounds the disingenuity.
Per bylaws, "The Core Committee is responsible for ensuring a high level of quality and consistency amongst all published specifications, and that all relevant perspectives and use cases are given due consideration."
I do not believe that this spec in its current form gives "all relevant perspectives... due consideration", and in fact misrepresents some perspectives. Nor do I see any justification in the metadoc for the inconsistencies noted above.
I appreciate the time and effort that many people have put into PSR-12 during its long run, and I want to be clear that I bear them no ill will, but in its current form I do not believe this specification is complete nor has process been properly followed.
--
Larry Garfield
la...@garfieldtech.com
Reply all
Reply to author
Forward
0 new messages