(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
  [email protected]

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a1c6528b-375f-4554-a327-0546ebc17559%40www.fastmail.com.

Reply via email to