Re: [PSR-12] Review phase review

[Adrien Crivelli]

>
> 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).

-- 
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/a102c16b-2057-4890-b0a2-feda76473532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12] Review phase review

[Joe T.]

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 > 
> 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

Re: [PSR-12] Review phase review

[Adrien Crivelli]

I agree with pretty much everything you say. Predefined order for members 
is good. And eliminating inconsistencies in the spec is more important than 
adopting style of existing code base just for the sake of not editing that 
code.

FYI there is a PR dealing with `declare` statement over 
there: https://github.com/php-fig/fig-standards/pull/992

-- 
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/cb80a9d2-c71d-4809-8d26-3b427d14a8c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12] Review phase review

[Joe T.]

i may be jumping into the end of a resolved discussion, but i'm new in the 
group and am looking for opportunities to offer my experiences to the 
PSR-12 review process.

*Re: properties first*
i fully support adding a recommendation to define all constants, 
properties, and methods declared with their own kind (preferably in the 
order listed). i can't recall ever finding a class that was more 
understandable by defining a property near its "relevant" functions midway 
down a class. If the point of a class-level member is to be accessible 
*anywhere* in the class, and for accessible members to be 
extensible/overridden by descendants, then organization is important. The 
use case specifies private properties, but i don't see the justification. 
If a descendant class needs to override the ancestor with its own private 
properties, there's an expectation set by the ancestor to define those 
properties in relatively close position to the original.

Shorter version: it would seem more appropriate that if a property 
"belongs" to only a limited scope of functions, they should be extracted to 
a separate structure (Trait or abstract class) and incorporated into the 
class that would use them.

i find it much cleaner to keep like-things together, and use PHPDoc 
comments with "*@see*" references if the member is designed for a narrow, 
limited purpose. My team's style guide requires not only member grouping, 
but grouping by modifier signature as well.


*Re: 4.5 return type colon spaces...*
Just to be a fly in the ointment, the argument that natural languages do 
one thing and code should follow suit could be used to support

public function foo ($bar, $baz)
// and
$this->foo ($bar, $baz);

over the prescribed

public function foo($bar, $baz)
// and
$this->foo($bar, $baz);

since most natural languages place a space before a parenthetical 
expression. Granted, the call format that includes a space looks silly, but 
it's legal and follows natural language. As such, i can see the contention 
that there's inconsistency to require removal the space before a ":" 
operator or to require collapsing white space inside declare(strict_types=1)
.

Spaces, in fact, have the appearance of several inconsistencies, 
particularly to potential new PHP coders:

   1. Name function declaration: no space between name and "("
   2. Anonymous function declaration: space between "function" and "(" - 
   seems to contradict #1.
   3. All non-unary operators: space on either side of the operator.
   4. Return type operator: space after colon, not before - seems to 
   contradict #3.
   5. Nullable argument / nullable return type: no space between "?" and 
   type - seems to contradict #3.
   6. Cast expressions like (int) '123': no mention (follow #3, or is 
   (int)'123' acceptable?)
   7. Declare strict types: no spaces at all, despite appearance as a 
   "function" call (similar to *list()* or *isset()*) and an assignment 
   operator. Seems to contradict #3.
   8. Spread/splat: no mention at all. Madness! ;-)
   
i realize a lot of these rules have been around for a long time, and come 
from surveys of programmers far more experienced than myself. But my 
understanding is part of the drive behind this updated PSR is to reexamine 
the existing guide and expand for new language features. Perhaps i'm 
mistaken. i have no strong opinion about where spaces are included or 
omitted, as long as they're done consistently, or at *least* with some 
justification for the rule. Simply saying "MUST" doesn't really help to 
explain *why* that's the recommended style. And as someone who has to 
convince a team of programmers to comply with style rules they will have to 
adapt to, justification goes a long way.

Okay, went a lot further with that than intended. Sorry.


Lastly, "splat/spread" *was* the best operator name until spaceship <=>, in 
my opinion. ;-) But splat is WAY more useful.

Thanks for the opportunity. Hope i haven't overstepped boundaries as a 
newcomer...
-jlt


On Monday, 11 December 2017 03:30:21 UTC-5, Alexander Makarov wrote:
>
> Thank you for the input. Meta should be definitely fixed. Some other 
> comments:
>  
>
>> * 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? 
>
>
> Generally it's true but there are exceptions. Private properties intended 
> for caching object instances are kept close to  methods in many libraries 
> I've seen and I can't say it's a bad practice. In fact, it makes it easier 
> to read such code.
>
> 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. 
>
>
> That would be very unnatural since in most natural languages there's no 
> space before ":" and a space after ":".
>
> * "we have taken a more prescriptive approach and def

Re: [PSR-12] Review phase review

['Alexander Makarov' via PHP Framework Interoperability Group]

https://groups.google.com/forum/#!topic/php-fig/vZOpga3xoLg

On Monday, December 11, 2017 at 12:00:48 AM UTC+3, Larry Garfield wrote:
>
> *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+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/0fb78008-c0cc-4579-a6ff-cc24419c27de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12] Review phase review

['Alexander Makarov' via PHP Framework Interoperability Group]

Thank you for the input. Meta should be definitely fixed. Some other 
comments:
 

> * 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? 


Generally it's true but there are exceptions. Private properties intended 
for caching object instances are kept close to  methods in many libraries 
I've seen and I can't say it's a bad practice. In fact, it makes it easier 
to read such code.

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. 


That would be very unnatural since in most natural languages there's no 
space before ":" and a space after ":".

* "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 is. Standards were mostly defined at that time. Then there was a period 
of validation with surveys.


On Monday, December 11, 2017 at 12:00:48 AM UTC+3, Larry Garfield wrote:
>
> *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+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/c25b34eb-8a32-4b35-af96-2911ea01ca93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12] Review phase review

[Adrien Crivelli]

Since we are pointing out at inconsistencies, I would also like to mention 
how `declare` is treated as an exception for no apparent reason.

Why should we write:

declare(strict_types=1);

When we could write the more consistent variant:

declare(strict_types = 1);

This exception does not make sense to me. And I know it will be pointed out 
that `declare` is a construct, but I fail to see how it has anything to do 
with spaces around operators. "6. Operators" specifically state that all 
operators must be surrounded by exactly 1 space. Why do it differently for 
`declare` ?

-- 
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/ba6bd599-c9eb-4da5-8a58-be9e6feddb55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.