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:*
>
> * 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.


On Tuesday, 13 February 2018 11:56:42 UTC-5, Larry Garfield wrote:
>
> 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 <javascript:>> 
> To: php...@googlegroups.com <javascript:> 
>
> *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 <javascript:>. 
> To post to this group, send email to php...@googlegroups.com <javascript:>. 
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/ 
>
> php-fig/4025631.r995PC85BO%40vulcan 
> <https://groups.google.com/d/msgid/php-fig/4025631.r995PC85BO%40vulcan>. 
> For more options, visit https://groups.google.com/d/optout. 
>
> -----------------------------------------

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/1b4a02cf-4bf1-446c-89de-a70f294ce544%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to