[PSR-12] Survey for outstanding issues

[Korvin Szanto]

Hi All,

I've been dragging my feet a bit on getting this survey completed and put out there, but I think we're now ready to get some real feedback. We will be accepting responses to this survey for about the next two weeks. I'm not going to be super specific about the timing of it, but at some point after two weeks has passed we will disable responses and start reviewing the results. 

Q: Who can take this survey?

A: Anyone who is familiar with PHP 7 and feels like they have a stake in this should add a response to this survey.

Q: Should I research PHP 7 first?

A: It's important that you know all of the syntax and features that we plan to be defining so you will do well by doing your research first.

Q: Do I need to read through PSR-12 first?

A: You certainly should. We do copy relevant text out directly from the PSR-12 documents into the survey so you can likely get through this survey without studying PSR-12 too hard.

Q: Why do you ask for my full name?

A: So that we can differentiate one reply from the next. A project representative may reply to the form twice, once for the project and once for themselves. If this makes you uncomfortable, feel free to put a handle in instead. Try to make it unique.

Q: Why do you ask for my email?

A: If we have any kind of misunderstanding or want to get more information we might shoot you an email. If this isn't something you want to share please do not share it.

Q: I'm a jokester, wouldn't it be funny if I made a joke response?

A: Please oh please do not make me sort through joke / fake replies :(

We hope to get a good idea of what the public, projects, and representatives think about what we have put together. We ask that you respond only once unless you are also a representative of a project in the PHP-FIG and ask that you read all directions in the survey carefully. 

After we've had time to sift through the results, we will post a summary on the list and post an anonymized list of responses that can be seen by all.

Please take this survey here: https://goo.gl/forms/SonvjwqicPoBBwwl1

PSR-12: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md

Meta: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md

Thanks for taking the time to respond!

Korvin & the PSR-12 team

[Aken Roberts]

Hi Korvin.

FYI: on Page 13 entitled "Return Type Declaration", the sub-header "Class instantiation parenthesis" is duplicated from the previous page.

Cheers,

Aken

[Iltar van der Berg]

Hello,

I'm missing decisions on a few php 7.1 implementations. I don't know if they are considered but it saves another PSR just for a few incoming changes:

Multiple exceptions in one catch:
https://wiki.php.net/rfc/multiple-catch

Class constant visibility modifiers:
https://wiki.php.net/rfc/class_const_visibility

Nullable arguments and return types:
https://wiki.php.net/rfc/nullable_types

List() with keys:
https://wiki.php.net/rfc/list_keys

Short syntax for list():
https://wiki.php.net/rfc/short_list_syntax

Regards,
Iltar

[Alexander Makarov]

Noted https://github.com/cs-extended/fig-standards/issues/39

[glen-84]

What were the results?

[Korvin Szanto]

We're still gathering responses from a few member projects unfortunately. We will announce results once those are in.

Best wishes,
Korvin

--
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.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/77bde59b-1072-4607-9a73-cc222bff8d82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Amo Chohan]

Hi all,

This might not be the correct place to post this (please point me in the right direction if, that's the case) but I have some thoughts on the topic of blank lines after the opening <?php tag in the spec.

From what I can see, there's some inconsistency in having a blank line after the opening tag. The examples in the spec also illustrate this.

Some examples without a blank line:

<?php
declare(strict_types=1);

<?php
namespace Vendor\Package;

Some examples with a blank line:

<?php

/**
 * This file contains an example of coding styles.
 */

declare(strict_types=1);

<?php

use Vendor\Package\Namespace\{
    SubnamespaceOne\ClassA,
    SubnamespaceOne\ClassB,
    SubnamespaceTwo\ClassY,
    ClassZ,
};

<?php

bar();

I think to enforce consistency, and (in my opinion) more aesthetically pleasing code, the standard should be to always have a blank line after the opening tag. Specific to namespaces, the convention to have a blank line after the opening tag is already adopted in a number of high profile PHP projects (Laravel, League packages, the Composer class loader, PHPSpec to name a few).

Does anyone have any feedback on this?

Again, my apologies if this isn't the right place for this suggestion.

Thanks for reading,

Amo

[Amo Chohan]

Does anyone have any thoughts on this?

On Monday, 17 October 2016 18:22:09 UTC+1, Korvin Szanto wrote:

[glen-84]

Amo, see https://groups.google.com/forum/#!topic/php-fig/kIqR-7WI690

FWIW, I also prefer to have the blank line.

[Amo Chohan]

Thank you Glen, I see that the subject has been discussed but I couldn't take away a definitive conclusion. In my humble opinion, I think the blank line should be enforced. It's cleaner, consistent and improves readability (of course that point may be subjective).

[Vinícius Dias]

Hello, everyone!

I miss a traits conflict resolution example in the PSR-12 documentation.

Wouldn't it be helpful?

Thanks in advance!