At this time, the recommendation from the meeting is for the PSR-12 team to watch and see what projects that adopt PHP 7 end up doing over the next 6-12 months, and take their lead from that. That doesn't necessarily mean "just do what they do", but be informed by it.
--
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/ba3d6af4-f731-47b9-801d-5d0282941871%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6KMrxY-m8JxL1tVKFd7kcP%3D_ncpQZ4%2BYGH4uZZTy%2B%2B9bg%40mail.gmail.com.
When no declare declarations are present there MUST be a blank line after the opening <?php tag.
I think this blank line is really pointless, just a waste of space. As testament to this being entirely unnatural, notice that this rule is contravened by almost every example in the PSR-12 doc! What good reason is there for requiring it? I don't recall seeing any code that does this.
Personally I would expect the first thing after an initial opening php tag to be a file-level docblock, but comments are not mentioned in PSR-12.
Marcus
I don't recall seeing any code that does this.
--
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/70611ae2-3290-4ba7-b3d8-2a63cc271ba1%40googlegroups.com.
...Perhaps this is because there are no community standards for languages features new in PHP 7.
--
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/56602806.9030800%40amiran.it.
--
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/56605146.7000501%40beccati.com.
1. I'd rather not require it as there isn't good consensus but there does seem to be good consensus that namespaces must not be on the same line as the opening php tag.
2. It wouldn't apply to anonymous classes? It's more about $var = \Foo(); vs $var = \Foo;
--
Thanks,
Michael Cullum
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/eed0e8ad-7cea-4e06-a638-8136f0a3e269%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMiODf-YQ1rc-EoZAx6yFxBT_ptZUXV_RoFKcuFAz9LLkQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAueXOWV%2BDoMaUsXNUpWJ1zZoRqa0smGBzZ2mfPJJT09OVpnwg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6LNuBMG0CeuboVghzN6RH82ZDsCRXGkioD4r__syvKxRw%40mail.gmail.com.
I much prefer to see code with the () always after a class name. Then I don't need to think about it, and if a parameter gets added later the parens are already there. It's in the same vein as {} on a for loop.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/56606AE8.2090104%40garfieldtech.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAueXOWV%2BDoMaUsXNUpWJ1zZoRqa0smGBzZ2mfPJJT09OVpnwg%40mail.gmail.com.
Hi all,PSR-12 [Extended Coding Style guide] was never intended to be that much more than PSR-2 ever was. It was intended to fix a few issues in PSR-2 with clarifications, or things that were meant but not said, and PHP 7 functionality primarily in addition to a couple of things that it was felt really should be included due to PHP 7 functionality (such as declare statements and operators).PSR-12 is now basically ready for review but I wanted to post to the list and ask people to have a quick look over it before that as once we enter review, we have a much more bureaucratic process with regards to making any necessary changes. Assuming nothing major comes up, we'll be looking to move it into review towards the end of the week. We have provided a non-comprehensive changelog of some of the most notable changes in the meta document should you wish you just review those parts and not the whole specification (which includes all of PSR-2).You can view it here: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.mdThanks all!--Michael
--
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/46563e9a-57d9-4a50-a06b-be10047334f9%40googlegroups.com.
+1 for always requiring a blank line after the opening tag.
--
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/f11f4467-4efb-43e0-af4c-183031611904%40googlegroups.com.
Exactly, Jason.On Fri, Dec 4, 2015 at 8:54 AM, Jason Judge <jason...@consil.co.uk> wrote:On Thursday, 3 December 2015 04:38:36 UTC, Woody Gilk wrote:+1 for always requiring a blank line after the opening tag.
Just to be clear, you mean this:
~~~
<?php
namespace Foo;
~~~
rather than this:
~~~
<?php
namespace Foo;
~~~
------ Jason
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/f11f4467-4efb-43e0-af4c-183031611904%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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/CAGOJM6LOOV0rsAjtswwqXJwRumFhXBiKbd3h%3DU-oZPNt-ZFVLg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWX8zvdsLw73mFEr7y7cEvk02XoX%3DtCLQtMthf%2B5UOmqMw%40mail.gmail.com.
It depends if we are looking for prevalence or readability for me. One person can create a style guide for a huge project that everyone else is then following. For me popularity of a style on GitHub doesn't make it "right".
G
--
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/bce2a133-a1a1-4ecc-9f1c-9560368fdfb7%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/VVZe7eI0Clg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bce2a133-a1a1-4ecc-9f1c-9560368fdfb7%40googlegroups.com.
--
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/5043217F-5FA4-486F-B142-81374AD9FC13%40gmail.com.
> On Dec 6, 2015, at 10:20, Michael Cullum <m...@michaelcullum.com> wrote:
>
> On the more general points being made:
> Obviously projects can use whatever criteria they wish to vote +1/-1, however I'd suggest that voting -1 because you aren't sure other projects would like it is counter productive.
There's an easy way to remedy that objection, and pretty much all others: do a survey of the member projects regarding each point-of-change you want to make. Then, if you don't like the majority preference, you can rationalize a rejection and replacement of that point-of-change.
Is it just me, or are the PSR-12 editor and sponsors resistant to that very reasonable and sensible approach, which worked to great success in PSR-2? If so, why are they resistant?
No it doesn't.
--
Thanks,
Michael Cullum
--
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/22d2c5d5-2f69-4a0b-be28-7238b411d4d9%40googlegroups.com.
--
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/56651018.70508%40garfieldtech.com.
Just doing my first review of PSR-12.----“Using multiple lines for traits, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the same line of the use keyword, and there MUST be only one trait per line.”The coding example then goes-on to show the `use` statement for Traits being used in a way that was identified and discarded for Namespace Aliases in PSR-2 discussions. The instruction is also somewhat ambiguous, allowing for multiple styles of using the `use` statement for Traits.IMO, we should keep the pattern for Namespace Aliases and Traits the same.
——Was the text for Closures always part of PSR-2? I’ve read this document dozens of times, and I did not recall that section being there before.I am curious as to the thinking behind requiring a space after the function keyword. Why didn’t the syntax for Closures match the syntax for Methods and Functions (i.e., no space between the function’s name and the opening paren)?
——1. “You MUST NOT use `use` statements for classes in the root namespace. Therefore you should use `throw new \Exception();` instead of `use Exception; throw new Exception();`”What is the rationale for this (in a nutshell)? I greatly prefer the latter format because it reads more cleanly to my eyes. If anything, I would prefer to NOT standardize this and leave it up to the project owner.
2. “Classes, functions or constants grouped together into a single line must be listed alphabetically.”In this case, the statement matches my preference. That said, I still think that this should NOT be standardized. For example, “Two” comes later in the alphabet than “Three”. And “Four” is before all of those. (Yes, this example is silly, but it illustrates my point.)
3. “Declare statements MUST contain no spaces and MUST look like declare(strict_types=1);.”This is counter to how we define variables. It seems to me that this format should match variables because that’s essentially what this is.
——“The opening bracket MAY be on the same line as the class keyword so long as the list of implements interfaces does not wrap. If the list of interfaces wraps, the bracket MUST be placed on the line immediately following the last interface.”IMO, all classes — anonymous or otherwise — should match in how they are defined. I recognize that this is written to match how Closures (a.k.a. Anonymous Functions) are formatted, but that doesn’t make sense to me either. Why do the “anonymous” things have a different style of definition from the concrete things?
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/etPan.5665409f.1fa8a635.c682%40skyzyx.local.
Sure, now is as good a time as any for member projects to figure out if they like these recommendations or not. That doesn't mean they have, or will. I'm sure you can appreciate the difference between PSR's focussed on one focussed interoperability aspect (like cache or logging) and PSR's which affect every line of code (like PSR-2 or PSR-12). Especially when the former (and PSR-2) were based on real-world usage while this doc is based on conjecture.
--
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/b7a0e39c-fdc4-4855-b62a-6f210ecb0ff0%40googlegroups.com.
1. “You MUST NOT use `use` statements for classes in the root namespace. Therefore you should use `throw new \Exception();` instead of `use Exception; throw new Exception();`”
I don't think anybody is suggesting any private discussion, or that this is an inadequate place to discuss this issue. My reservations are for deciding the standards without an exhaustive discussion or empirical data. Thank you for pinging the people - hopefully we can get more clarity here.
--
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/34ab34ff-bb17-4a43-8a01-c1603984b1c0%40googlegroups.com.
> On Dec 7, 2015, at 18:22, Korvin Szanto <korvin...@gmail.com> wrote:
>
> I think it is a shame that we feel that the PHP-FIG mailing list is not an adequate place to communicate with PHP-FIG member projects. I'm sad to hear that we have 45 member projects - some of the most influential projects powering the internet as we know it - in our ranks yet we feel that we cannot discuss this as a group in public on the mailing list and instead feel the need to discuss and survey privately through other channels. I hope some day we can actually all collaborating and work together the way we should be working together.
It's easy to do a survey: you, personally, review the 45 codebases; and you, personally, report the results. It's not hard, although it is a little more like *work* than you might prefer.
--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
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/8166B98D-5FAD-4779-82B4-AFBCD6DCC5F3%40gmail.com.
--
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/8166B98D-5FAD-4779-82B4-AFBCD6DCC5F3%40gmail.com.
Some of my thoughts:
---
> You MUST NOT use use statements for classes in the root namespace. Therefore you should use throw new \Exception(); instead of use Exception; throw new Exception();WAT?!?! Why? Seems arbitrary. It also seems needlessly annoying to implement that as a rule in code analysis tools.
---
In the declare/namespaces/use section (and in the entire document), the term "compound namespaces" is used once. It's not really defined well, and it is also not explained in any way, other than in the code sample following the use of the term, that mutli-line "compound namespaces" are actually allowed.Perhaps borrowing some words from the extends/implements section could help:
> Lists of implements and extends MAY be split across multiple lines, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the next line, and there MUST be only one interface per line.
And though I understand that the rule stating "There MUST be one use keyword per declaration" does not actually contradict with the idea of compound namespaces, it might seem that way to a reader. Seems like some clarifications are needed around this concept of compound namespaces.
---
> When instantiating a new class, parenthesis MUST always be present even when there are no arguments passed to the constructor.The only time I really hate this rule is when you are calling a method like this:$result = (new Thing)->doStuff($args);I'm not sure I care that much though.
---
> Using multiple lines for traits, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the same line of the use keyword, and there MUST be only one trait per line.Why would we allow multi-line trait using when we don't allow multi-line namespace using? Seems inconsistent without a reason.
Also, the grammar in this description is off. That first sentence isn't a complete sentence. You may want to clean that up.
---
In the function arguments and return types section it says:
> When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.
This does not adequately address the situation where you have arguments on multiple lines AND a return type declared.
public function aVeryLongMethodName(
int $arg1,
string $arg2,
array $arg3 = []
): string {
// method body
}
---There are no examples of closures with a return type declared.
---That's all for now!--
Jeremy Lindblom (@jeremeamia)
Software/Platform Engineer at Engrade (part of McGraw-Hill Education)Co-founder of the Pacific Northwest PHP Conference (@PNWPHP)Looking for a senior-level software engineering position doing PHP? I have some available with McGraw-Hill Education in Seattle and Los Angeles (Santa Monica or Irvine). Contact me for me more information.--On Mon, Dec 7, 2015 at 4:26 PM, Christopher Pitt <cgp...@gmail.com> wrote:--I don't think anybody is suggesting any private discussion, or that this is an inadequate place to discuss this issue. My reservations are for deciding the standards without an exhaustive discussion or empirical data. Thank you for pinging the people - hopefully we can get more clarity here.
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/34ab34ff-bb17-4a43-8a01-c1603984b1c0%40googlegroups.com.
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/CALDVupLeOVYsuVEor19oj-pvCf%2B_gHqg-n-EaHm%3DYi%3DaqGRFeA%40mail.gmail.com.
> On Dec 7, 2015, at 19:20, Korvin Szanto <korvin...@gmail.com> wrote:
>
> On Mon, Dec 7, 2015 at 4:38 PM Paul M. Jones <pmjo...@gmail.com> wrote:
>
> > On Dec 7, 2015, at 18:22, Korvin Szanto <korvin...@gmail.com> wrote:
> >
> > I think it is a shame that we feel that the PHP-FIG mailing list is not an adequate place to communicate with PHP-FIG member projects. I'm sad to hear that we have 45 member projects - some of the most influential projects powering the internet as we know it - in our ranks yet we feel that we cannot discuss this as a group in public on the mailing list and instead feel the need to discuss and survey privately through other channels. I hope some day we can actually all collaborating and work together the way we should be working together.
>
> It's easy to do a survey: you, personally, review the 45 codebases; and you, personally, report the results. It's not hard, although it is a little more like *work* than you might prefer.
>
>
> While my involvement in PSR-12 has certainly been lacking, I really don't appreciate you attacking my work ethic here in a position that I volunteered to fill. Can you please try to find a professional way to get your ideas across without attacking me personally?
I'm not attacking "you personally". I'm stating the level-of-involvement I expect from the Editor, Coordinator, and Sponsor of a "Proposed Standards Recommendation." If the holders of those roles cannot be bothered to expend some effort beyond "nobody has complained" then I admit I lack confidence in the contents of the PSR itself.
--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
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/9EAADBFA-F36B-4526-9D91-8747C4C8E4C4%40gmail.com.
One thing I really want this PSR to address is empty line indentation. E.g. if you are inside a function and you are adding anempty line that lines SHOULD still have the indentation whitespace. Editors like Atom remove any trailing whitespace including indentation bydefault, which makes browsing code rather annoying since the cursor is jumping to the very left of the screen each time you encounter an empty line.Can we please address that?
Hi Ryan,Thanks for your feedback!I've put comments inline on the changes. In regards to the new statements you'd like to see added I've not commented as I'd rather avoid adding new statements now. I'd also add that most of your changes break BC quite a bit or would enforce behaviour instead of just coding style, we discussed what was out of scope in reference to whether we should require strict types and we decided that those kinds of things do not really belong here.This email thread is rather large so if I miss anyone elses comments please let me know.--Michael COn 7 December 2015 at 08:17, Ryan Parman <ry...@ryanparman.com> wrote:Just doing my first review of PSR-12.----“Using multiple lines for traits, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the same line of the use keyword, and there MUST be only one trait per line.”The coding example then goes-on to show the `use` statement for Traits being used in a way that was identified and discarded for Namespace Aliases in PSR-2 discussions. The instruction is also somewhat ambiguous, allowing for multiple styles of using the `use` statement for Traits.IMO, we should keep the pattern for Namespace Aliases and Traits the same.I'm not entirely sure what you mean. Would you mind submitting a pull request with what you think makes more sense as that would make it easier to see what you mean?——Was the text for Closures always part of PSR-2? I’ve read this document dozens of times, and I did not recall that section being there before.I am curious as to the thinking behind requiring a space after the function keyword. Why didn’t the syntax for Closures match the syntax for Methods and Functions (i.e., no space between the function’s name and the opening paren)?Closures was in PSR-2 and I'd rather not change it.
——1. “You MUST NOT use `use` statements for classes in the root namespace. Therefore you should use `throw new \Exception();` instead of `use Exception; throw new Exception();`”What is the rationale for this (in a nutshell)? I greatly prefer the latter format because it reads more cleanly to my eyes. If anything, I would prefer to NOT standardize this and leave it up to the project owner.
2. “Classes, functions or constants grouped together into a single line must be listed alphabetically.”In this case, the statement matches my preference. That said, I still think that this should NOT be standardized. For example, “Two” comes later in the alphabet than “Three”. And “Four” is before all of those. (Yes, this example is silly, but it illustrates my point.)Sure but how often do you name classes with numbers? I don't really think it matters as that's quite an isolated example (Where another ordering system for words makes more sense because those words represent numbers) but if other people have objections we can revisit this.
One thing I really want this PSR to address is empty line indentation. E.g. if you are inside a function and you are adding anempty line that lines SHOULD still have the indentation whitespace. Editors like Atom remove any trailing whitespace including indentation bydefault, which makes browsing code rather annoying since the cursor is jumping to the very left of the screen each time you encounter an empty line.
On Tuesday, 8 December 2015 09:08:01 UTC, Dracony wrote:One thing I really want this PSR to address is empty line indentation. E.g. if you are inside a function and you are adding anempty line that lines SHOULD still have the indentation whitespace. Editors like Atom remove any trailing whitespace including indentation bydefault, which makes browsing code rather annoying since the cursor is jumping to the very left of the screen each time you encounter an empty line.Can we please address that?
The current intention of the proposal is that no trailing whitespace is allowed on any line:
https://github.com/php-fig/fig-standards/pull/692
Originally it said that trailing whitespace is not allowed on non-blank lines, which sounds like it was trying to say that lines containing only indentation characters are allowed (possibly for the reason you are finding with some editors and code formatters), so it has changed from that.
Why don't you give a minimal example of what you would like to be able to put in your code, and we can take it from there. A real example may be a little less ambiguous. As it is, the ambiguity of what is "a non-blank line" is an issue to me. Nowhere does is say a line *of code*. Trailing whitespace in a non-code block of a PHP file - why not?
On Wednesday, December 2, 2015 at 11:08:20 AM UTC+1, Michael Cullum wrote:Hi all,PSR-12 [Extended Coding Style guide] was never intended to be that much more than PSR-2 ever was. It was intended to fix a few issues in PSR-2 with clarifications, or things that were meant but not said, and PHP 7 functionality primarily in addition to a couple of things that it was felt really should be included due to PHP 7 functionality (such as declare statements and operators).PSR-12 is now basically ready for review but I wanted to post to the list and ask people to have a quick look over it before that as once we enter review, we have a much more bureaucratic process with regards to making any necessary changes. Assuming nothing major comes up, we'll be looking to move it into review towards the end of the week. We have provided a non-comprehensive changelog of some of the most notable changes in the meta document should you wish you just review those parts and not the whole specification (which includes all of PSR-2).You can view it here: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.mdThanks all!--Michael
--
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/8d7aff8a-9fdc-48ed-926a-4cf209219167%40googlegroups.com.
On Tuesday, 8 December 2015 00:00:28 UTC, Michael Cullum wrote:Hi Ryan,Thanks for your feedback!I've put comments inline on the changes. In regards to the new statements you'd like to see added I've not commented as I'd rather avoid adding new statements now. I'd also add that most of your changes break BC quite a bit or would enforce behaviour instead of just coding style, we discussed what was out of scope in reference to whether we should require strict types and we decided that those kinds of things do not really belong here.This email thread is rather large so if I miss anyone elses comments please let me know.--Michael COn 7 December 2015 at 08:17, Ryan Parman <ry...@ryanparman.com> wrote:Just doing my first review of PSR-12.----“Using multiple lines for traits, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the same line of the use keyword, and there MUST be only one trait per line.”The coding example then goes-on to show the `use` statement for Traits being used in a way that was identified and discarded for Namespace Aliases in PSR-2 discussions. The instruction is also somewhat ambiguous, allowing for multiple styles of using the `use` statement for Traits.IMO, we should keep the pattern for Namespace Aliases and Traits the same.I'm not entirely sure what you mean. Would you mind submitting a pull request with what you think makes more sense as that would make it easier to see what you mean?——Was the text for Closures always part of PSR-2? I’ve read this document dozens of times, and I did not recall that section being there before.I am curious as to the thinking behind requiring a space after the function keyword. Why didn’t the syntax for Closures match the syntax for Methods and Functions (i.e., no space between the function’s name and the opening paren)?Closures was in PSR-2 and I'd rather not change it.
Probably better not to mention it at all in this PSR, if it is not changing. It is difficult to pick out what has been duplicated from PSR-2, what is an extension to PSR-2, and what are new rules that have been thrown in. If PSR-12 is an extension to PSR-2 then IMO it would be better to describe how it extends PSR-2 and not to have an arbitrary mix of extension and repetition. If it's a *replacement* of PSR-2, then that's something else altogether.
——1. “You MUST NOT use `use` statements for classes in the root namespace. Therefore you should use `throw new \Exception();` instead of `use Exception; throw new Exception();`”What is the rationale for this (in a nutshell)? I greatly prefer the latter format because it reads more cleanly to my eyes. If anything, I would prefer to NOT standardize this and leave it up to the project owner.
What is the rationale for this (in a nutshell)? I don't do this, and many other projects don't do this. Some projects do.
2. “Classes, functions or constants grouped together into a single line must be listed alphabetically.”In this case, the statement matches my preference. That said, I still think that this should NOT be standardized. For example, “Two” comes later in the alphabet than “Three”. And “Four” is before all of those. (Yes, this example is silly, but it illustrates my point.)Sure but how often do you name classes with numbers? I don't really think it matters as that's quite an isolated example (Where another ordering system for words makes more sense because those words represent numbers) but if other people have objections we can revisit this.
I'll voice an objection then, so this does not get brushed under the carpet of "your use-case isn't very common".
What is the reasoning behind ordering these things alphabetically? It is a burden on the developer, and I have seen no reason given for why it should be enforced.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2f6ab734-5149-4ff4-baed-2ba32b279371%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWUejuRLEGM0JeFBiFsrNej04CbuZiFiOHAYXb0mAhOgbQ%40mail.gmail.com.
This guide extends and expands on PSR-2, the coding style guide and PSR-1, the basic coding standard.
PSR-2 was accepted in 2012 and since then a number of changes have been made to PHP which have implications for coding style guidelines. Whilst PSR-2 is very comprehensive of PHP functionality that existed at the time of writing, new functionality is very open to interpretation. This PSR therefore seeks to clarify the content of PSR-2 in a more modern context with new functionality available, and make the errata to PSR-2 binding.
This section is ambiguous to me; are there three types of line lengths? None, 120 and 80? When should which be enforced, or is this actually just moot?There MUST NOT be a hard limit on line length.
The soft limit on line length MUST be 120 characters; automated style checkers MUST warn but MUST NOT error at the soft limit.
Lines SHOULD NOT be longer than 80 characters; lines longer than that SHOULD be split into multiple subsequent lines of no more than 80 characters each.
Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
This technically states that all code must be indented with 4 spaces while the intention is that each level of indentation is indicated by 4 spaces. (though I am not sure indicated is an accurate word here)
The PHP types and keywordsint
,true
,object
,float
,false
,mixed
,bool
,null
,numeric
,string
andresource
MUST be in lower case
Use statements MUST be in blocks, grouped by varying entity (classes [inc. interfaces and traits], functions or constants). To elaborate, this means that any and all classes are in a block together; any and all functions are in a block together; and any and all constants must be grouped together. Within each block there MUST be no blank lines. If a block has multiple lines there MUST be a blank line before the first line and a blank line after the last line.
Classes, functions or constants grouped together into a single line must be listed alphabetically.
When wishing to declare strict types in files containing markup outside PHP opening and closing tags MUST, on the first line, include an opening php tag, the strict types declaration and closing tag.
Using multiple lines for traits, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the same line of the use
keyword, and there MUST be only one trait per line.
When you have a return type declaration present there MUST be one space after the colon with followed by the type declaration. The colon and declaration MUST be on the same line as the argument list closing parentheses with no spaces between the two characters. The declaration keyword (e.g. string) MUST be lowercase.
somefunction($foo, $bar, [ // ... ], $baz);
- The structure body MUST be indented once
A for
statement looks like the following
A foreach
statement looks like the following.
All binary and ternary operators MUST be preceded
--
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/75d6f6a8-ea02-485d-8c4e-9c7d9fa7e0d3%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BXQXvrrFgEwR9xzRJ5RTGicv5gCjwSOh%3DWbK11u7yv%2BQ%40mail.gmail.com.
I am not through the whole thread yet but the current version still misses that blank line after the opening PHP tag. This makes it impossible to add a file-level PhpDoc to any file and introduces a huge BC for PhpDoc. It is also inconsistent since all other structural elements require blank lines before and after them. PSR-2 already contains enough inconsistency, stop the madness and correct this. Imho there is no need for a survey on this one, simply because it introduces a BC for PhpDoc and is inconsistent.
--
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/02686502-23c1-4cde-b0c9-dde0c0dad1de%40googlegroups.com.
Richard,I agree... that's why no such instruction/rule is in the specification requiring a blank line after `<?php`?--Michael C
<?php
/**
* @author Richard Fussenegger <richard@fussenegger>
* @copyright 2016 Richard Fussenegger
* @license MIT
*/
declare(strict_types=1);
// More code …
<?php
/**
* @author Richard Fussenegger <richard@fussenegger>
* @copyright 2016 Richard Fussenegger
* @license MIT
*/
declare(strict_types=1);
// More code …
<?php
declare(strict_types=1);
declare(ticks=1);
namespace PhpFig\Psr12;
const NS_CONST_1 = 1;
const NS_CONST_2 = 2;
function nsFn() {
// Within block!
}
use Something;
use Something\Else;
class CodingStandard{
// Within block!
public function fn() {
// Within block!
}
}
--
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/b9353abb-0280-4287-a3bb-2cd3bbe47eef%40googlegroups.com.
Have I missed anything?-------------------------------So I think the vast majority of the issues raised in this topic have been addressed or changed in the specification now. If there are any points I've missed please do feel free to re-highlight them, this is a large thread and stuff does get missed and I certainly don't want any issues or objections to get swept under the carpet.
Link to the spec again in case you don't have it to hand: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
Happy new year all!
$app->get('/hello/{name}', function ($name) use ($app) { return 'Hello '.$app->escape($name); });
On 01/02/2016 04:31 PM, Michael Cullum wrote:
Have I missed anything?-------------------------------So I think the vast majority of the issues raised in this topic have been addressed or changed in the specification now. If there are any points I've missed please do feel free to re-highlight them, this is a large thread and stuff does get missed and I certainly don't want any issues or objections to get swept under the carpet.
*snip*
Link to the spec again in case you don't have it to hand: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
Happy new year all!
Other random notes as I read through the spec:
4.0: The text here uses "parentheses" to refer to (). The metadoc, however (section 5), refers to those characters as brackets. Brackets are these things: []. :-) Please update the metadoc.
4.1: "Lists of implements and extends MAY be split across multiple lines, where each subsequent line is indented once."
That should be lists of implements, as extends is never a list.
4.3/4.4: Why is not using a _ prefix as a visibility modifier only a SHOULD NOT, rather than MUST NOT? It's 2016 and we're talking about PHP 7. Those were a PHP 4 convention that makes no sense at all today, and I've not seen it in a long time myself. Why not go all the way on that?
4.5: The metadoc says that the space on only one side of the return type colon is "for consistency". With what? I don't see anything else where that would be consistent with it. Rather, I see almost everything else having a space on either side, save for functionName(. Looking at the anon function example right above it:
$app->get('/hello/{name}', function ($name) use ($app) { return 'Hello '.$app->escape($name); });
function space param-list space use space use-list space brace. Everything there has a space. The same is true for control structures. Why make : odd-man-out? Putting a space on both sides of the colon seems both more consistent and more readable to me.
5.6: "A try catch finally block" is better read as "A try-catch-finally block". The highlighting on the 3 keywords is too faint and insufficient, especially when accessibility is taken into account. Dashes FTW.
6: Why is the string concat operator not a binary operator? It takes a pre-argument and a post-argument, and evaluates to a new argument, exactly like + does. (Drupal used to have string-concat only sometimes take a padding space. We eventually concluded that was stupid and moved to always having the padding space, exactly as binary operators here.)
7: As with the header block (see previous email), the wording here is quite clumsy. The intent appears to be "every section separated by a space if it exists", but with collapsed spaces for the parens. So just say that. The wording here, without the example, would take too long for my brain to parse.
The text would also appear to forbid even super-short inlined anon functions:
array_map(function ($a) { return $a->b(); }, $arr);
Is that intentional? If the body is single-line and short I'd argue that is more readable than forcing it to multiple lines. (This may be leftover from PSR-2, I'm not sure.)
--Larry Garfield
--
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/568984EF.10208%40garfieldtech.com.
On 3 January 2016 at 20:30, Larry Garfield <la...@garfieldtech.com> wrote:
4.5: The metadoc says that the space on only one side of the return type colon is "for consistency". With what? I don't see anything else where that would be consistent with it. Rather, I see almost everything else having a space on either side, save for functionName(. Looking at the anon function example right above it:
$app->get('/hello/{name}', function ($name) use ($app) { return 'Hello '.$app->escape($name); });
function space param-list space use space use-list space brace. Everything there has a space. The same is true for control structures. Why make : odd-man-out? Putting a space on both sides of the colon seems both more consistent and more readable to me.
Korvin might have a better recollection of the reasons around this than I (https://gist.github.com/michaelcullum/c025f3870c9ea1dd2668#file-returntypesspacing-php) but I believe the intention was to create the visual effect that the closing parameter bracket and colon look more like one character. As nothing can ever go between those two characters, the colon is more of a modifier to the closing parentheses to tell you to expect a return type declaration as opposed to enclosing a statement or number of statements as parentheses/square brackets/curly braces are used in PHP. A crude example of having two pieces of punctuation next to each other (instead of the second piece of punctuation being more of a modifier to the first pieces) would be `statement;;` vs `statement;`. I've not really talked about consistency here so either the meta document could be incorrect in that aspect or I'm forgetting other reasons for that decision that Korvin might remember. Our decision was also influenced by this being the most common way used in code on github (from some crude searching), php documentation and the RFCs but this wasn't the deciding factor.
6: Why is the string concat operator not a binary operator? It takes a pre-argument and a post-argument, and evaluates to a new argument, exactly like + does. (Drupal used to have string-concat only sometimes take a padding space. We eventually concluded that was stupid and moved to always having the padding space, exactly as binary operators here.)
String concat is a binary operator, hence it says excluding the string concatenation operator. The reason for the exclusion was to reduce migration friction from PSR-2. For PSR-12 one thing we wanted to do was avoid breaking any more BC than was necessary in order to make that migration path easier. I'd be +1 to removing the exclusion if people think that wouldn't be a problem though.
Opening PHP tag <?php
File-level docblock.
One or more declare statements.
The namespace declaration of the file.
One or more class-based `use` statements.
One or more function-based `use` statements.
One or more `const`-based use statements.
The remainder of the code in the file.
<?php
/** file level docblock */
declare
namespace
use
class
it might break some PhpDoc implementations