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 firsti 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:
- Name function declaration: no space between name and "("
- Anonymous function declaration: space between "function" and "(" - seems to contradict #1.
- All non-unary operators: space on either side of the operator.
- Return type operator: space after colon, not before - seems to contradict #3.
- Nullable argument / nullable return type: no space between "?" and type - seems to contradict #3.
- Cast expressions like (int) '123': no mention (follow #3, or is (int)'123' acceptable?)
- 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.
- 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