PSR-2 and PHP 7

1,490 views
Skip to first unread message

Nigel Greenway

unread,
Aug 12, 2015, 6:25:43 AM8/12/15
to PHP Framework Interoperability Group
Hi all,

I have started using PHP7 and have come to a PSR2 issue.

What are we saying as best practise for the return type hinting?

No problems here:

public function addNumbers(int $a, int $b) : int
{
   
return $a + $b;
}

But what about when we add method arguments on separate lines?:

public function addNumbers(
   
int $a,
   
int $b
):int {
   
return $a + $b;
}

Can't find anything about it at the moment so thought I would raise it?

Cheers

Wycliff Bironga

unread,
Aug 12, 2015, 6:40:08 AM8/12/15
to PHP Framework Interoperability Group
Are you encountering an error? What's the issue with method args on separate lines?

Nigel Greenway

unread,
Aug 12, 2015, 6:47:43 AM8/12/15
to PHP Framework Interoperability Group
No error or issue. :)

I am asking what considerations have been given about PSR2 with PHP 7 in regards to return type hinting when using separate lines for methods?

The example I gave is what I have started to use but would like to stick to how the PHP-FIG go so wanted clarification?

Alexander Makarov

unread,
Aug 12, 2015, 9:23:02 AM8/12/15
to PHP Framework Interoperability Group
It basically doesn't cover it...

Nigel Greenway

unread,
Aug 12, 2015, 9:47:28 AM8/12/15
to PHP Framework Interoperability Group
@alexander: Thats my question, is it going to cover it before 7 is production ready? :)

Alexander Makarov

unread,
Aug 14, 2015, 6:18:09 AM8/14/15
to PHP Framework Interoperability Group
No. Existing PSRs aren't going to be update. New one could be created to cover more code style rules. You can propose one if you feel you can make it good.

Michael Cullum (phpBB)

unread,
Aug 21, 2015, 3:22:54 PM8/21/15
to PHP Framework Interoperability Group
Alexander,

The problem being highlighted here is perhaps that there aren't enough changes in PHP 7 that affect coding style to warrant a new PSR, however if these things are not included in a PSR then projects using a PSR will begin to either have differing coding styles throughout their codebase, or it will start to become a case of projects that 'support PSR-2 with a few extra rules', which will differ between projects.

The best way forward perhaps would not be adding new rules to an existing PSR (the PSR amendment bylaw doesn't allow cases such as this anyway), but adding clarification errata on how the rules work with newly available syntax (specifically in this instance return type declarations) so that interpretation is consistent both within projects, and between projects (important for interaction with CS tools).

We do have a bylaw in place for errata (https://github.com/php-fig/fig-standards/blob/master/bylaws/004-psr-workflow.md#36-errata) and I think clarification through the errata needs to be done quickly before projects using PSR-2 start using PSR-7 syntax in differing fashions.

--
Thanks,
Michael C

Korvin Szanto

unread,
Aug 21, 2015, 3:26:52 PM8/21/15
to php...@googlegroups.com
Michael, I disagree that an amendment PSR can somehow be too small, there is plenty in terms of PHP7 syntax changes that warrant a large effort to define a solid recommendation (uniform variable support comes to mind).



--
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/203b39b3-7b59-41f9-a32e-552df555fb09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages