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.
