I don't necessarily agree with this point in particular - I mentioned PSR
just-by-driveby, since whoever does follow that convention will face this
issue - but the scope of the proposal is not limited to PSR adopters. It's
also worth pointing out that PSR is not an "official" coding guideline for
PHP, and therefore we should probably not limit the scope to it, simply
because regardless if the brackets are on the same line or not, they are
still there.
IMO, this is a language issue - topical, cosmetic, and minor - but language
issue nevertheless, in fact, exactly like the one had for attribute syntax.
Let's gather some feedback and see.
- Matīss
On Mon, May 10, 2021 at 10:55 AM Marco Pivetta <ocram...@gmail.com> wrote:
>
> On Mon, May 10, 2021 at 10:50 AM Matīss Treinis <mrtrei...@gmail.com>
> wrote:
>
>> Hi Marco,
>>
>> I am not sure, that's why I am asking for feedback.
>>
>> I have been converting a ton of code to use constructor property
>> promotion and the absolute majority ends up with the method body being
>> empty. I reckon this could be a nice eye-candy to have, however, it's
>> nothing more than that.
>>
>> Another point to be made here, as far as my interpretation of PSR-12, the
>> curly braces occupy two lines for methods with multiline arguments. So for
>> whoever follows PSR-12, it's more like this, with brackets just dangling
>> there across 2 lines.
>>
>> [...]
>> class Foo {
>> public function __construct(
>> private Bar $bar,
>> private Baz $baz
>> ) {
>> }
>> }
>>
>
> Given that:
>
> * `{}` can already represent what you want
> * the issue is more of a coding-style related topic
>
> I suggest bringing this up in a new PSR instead. Consider that PSR-1,
> PSR-2 and PSR-12 were designed pre-PHP-8, so they will need adjustments
> again, but AFAIK nothing has moved yet, since the ecosystem is still
> adapting to the PHP 8 changes (I myself haven't finished adopting it on
> many of my libraries).
>
> If this is relevant to you right now, add an exclusion to your
> `phpcs.xml.dist` instead: easier and less painful than expanding the
> language for such a tiny detail.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
