Re: [VOTE] Secretary Election

1. Alessandro Lai On Friday, October 20, 2017 at 12:17:12 AM UTC+3, Michael Cullum wrote: > > Hi all, > > We've been attempting to get more nominations so this has been delayed a > few times but we now have three candidates so we're rolling with it. > > Full information about the Secretary vote a

Re: Proposal for extended coding style guide

Same here. Using 1st case. On Monday, October 23, 2017 at 12:28:17 PM UTC+3, Alessandro Lai wrote: > > This is an interesting topic. I've always found inconsistencies on this > topic, since some formatters use the first case, others the latter. > > I'm inclined for the first case, since it's norm

Re: Proposal for extended coding style guide

Results are in the meta doc. As far as I remember, type casting was not in the survey. On Tuesday, October 24, 2017 at 6:35:10 AM UTC+3, Adrien Crivelli wrote: > > I also use the second case. > > Should we open a poll for that ? Or was it covered in the survey that were > done a long time ago ?

Re: Should new PSRs support PHP5?

7.1 should be fine. 7.0 has a limitation for not allowing nulls while type-hinted and that's a deal breaker. On Wednesday, October 25, 2017 at 7:13:54 PM UTC+3, Sara Golemon wrote: > > On Saturday, October 21, 2017 at 4:19:20 PM UTC-4, Tobias Nyholm wrote: >> >> While reviewing PSR-18 I found a s

Re: [VOTE][WG] PSR-12 Readiness Vote

+1 On Tuesday, November 7, 2017 at 11:06:09 PM UTC+3, Korvin Szanto wrote: > > Hi Everyone, > We in the PSR-12 working group believe we are ready to move forward with > our draft. To that end, we are holding a public vote amongst ourselves on > the mailing list in order to ensure the process is

Re: [PSR-12] Review phase review

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

Re: [PSR-12] Review phase review

https://groups.google.com/forum/#!topic/php-fig/vZOpga3xoLg 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

Re: [PSR-12] Line-length enforcement

Looks like a good change. PSR except, maybe, meta should not dictate on how exactly to achieve its goals. On Friday, December 22, 2017 at 2:08:18 PM UTC+3, Chris Emerson wrote: > > Hi all, > > First of all, I know that it is specifically stated as a non-goal of this > PSR to change anything in P

Re: PSR-12: closing brace MUST NOT be followed by any comment

Any good IDE and even simple code editors could highlight matching { and } so I see no practical use in having a comment. On Tuesday, December 26, 2017 at 10:12:47 AM UTC+3, Joe T. wrote: > > Refactoring to smaller blocks isn't always practical, particularly with > older legacy code. i've often

[CC nomination] Michael Cullum

I hereby nominate Michael Cullum for the Core Committee. Michael was both involved in actual PSRs and was group secretary for two years. He already mentioned that he planned to step down as secretary but he's keen to stay involved with many specs and furthering the FIG's mission from a differe

Re: Console Psr

Console is a bit different. It may have additional inputs in the middle of processing and that's usually the case. On Friday, January 5, 2018 at 11:35:46 PM UTC+3, Majid abdolhosseini wrote: > > Hi, > I think an application is bunch of logic and data manipulation ( R/W ) > > every application (in

Re: [VOTE][Internals] Secretary election

+1 for Mark Railton from Yii framework. On Friday, January 12, 2018 at 5:37:01 PM UTC+3, Alessandro Lai wrote: > > Hello everyone, > as specified in the previous thread ( > https://groups.google.com/forum/?fromgroups#!topic/php-fig/EKDIoSHqMSo), > yesterday at midnight the nominations ended, and

Re: Working Group for PSR-5

I'm still interested as well so if you need my input, I'm ready to make it. On Tuesday, February 13, 2018 at 4:04:45 AM UTC+3, Chuck Burgess wrote: > > At this point, I have a CC sponsor and one WG member. > > Joe T., are you still interested? > > On Jan 31, 2018 09:45, "Gary Hockin" > wrote: > >>

Re: [PSR-12] Operators MUST be preceded and followed by at least one space

Yes, it was intentionally left open for alignment purpose. On Monday, April 23, 2018 at 7:30:06 AM UTC+3, Greg Sherwood wrote: > > On Monday, 23 April 2018 14:16:40 UTC+10, Daniel Hunsaker wrote: >> >> I often find it helpful to align operators other than assignment >> operators, too. Comparison,

Re: [PSR-12] Spacing for INSTEADOF and AS in trait trait use blocks

At least one may make sense for aligning: > Hi, > > I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question > about this section at the bottom of 4.2: > > When using the insteadof and as operators they must be used as follows >> taking note of indentation, spacing and new line

Re: [PSR-12] Closure guidelines for anon classes

1. The opening brace MUST go on the same line, and the closing brace MUST go on the next line following the body. On Tuesday, April 24, 2018 at 1:53:06 AM UTC+3, Greg Sherwood wrote: > > Hi, > > I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question > about this section: > >

Re: [PSR-12] Casting variable section

Lowercase and short forms for keywords are covered. Spaces aren't addressed because it is quite controversial. Both space after casting and no-space after casting styles are used widely. On Friday, December 28, 2018 at 6:07:21 PM UTC+3, Georgios Mponos wrote: > Hello, > > I am writing this thre

Re: [PSR-12] Casting variable section

Agree. On Tuesday, January 8, 2019 at 3:33:20 PM UTC+3, Alessandro Lai wrote: > > I agree, spacing before could be required and spacing inside could be > forbidden. > > Il giorno giovedì 3 gennaio 2019 20:35:00 UTC+1, Georgios Mponos ha > scritto: >> >> Elaborating further: >> >> >> case 1: >>

Re: [PSR-12] Casting variable section

I'll pull-request. On Wednesday, January 16, 2019 at 12:56:14 PM UTC+3, Alexander Makarov wrote: > > Agree. > > On Tuesday, January 8, 2019 at 3:33:20 PM UTC+3, Alessandro Lai wrote: >> >> I agree, spacing before could be required and spacing inside could be >> forbidden. >> >> Il giorno giovedì

Re: [PSR-12] Casting variable section

After thinking about it more, spaces before should not be mentioned because these are covered by operators and statements already: >From section 5, control structures: > - There must not be a space after the opening parenthesis > - There MUST NOT be a space before the closing parenthesis >From

Re: [PSR-12] Casting variable section

Merged. Thank you raising the issue, Georgios. On Friday, January 18, 2019 at 1:41:12 PM UTC+3, Alexander Makarov wrote: > > After thinking about it more, spaces before should not be mentioned > because these are covered by operators and statements already: > > From section 5, control structures:

Re: [VOTE][WG] PSR-12 Readiness Vote

+1 On Monday, January 28, 2019 at 8:25:37 PM UTC+3, Korvin Szanto wrote: > > Hi Everyone, > After a few revisions and additions, the PSR-12 working group is again > ready to transition out of draft and into review. > > Please do not vote in this thread unless you are listed as a member of the >

Re: Request to Join PHP-FIG as a Member Project

Hello Buster, Do you want to vote or to participate in standard creation? As far as I know, anyone could join a working group for the standard. Being a voting member isn't required. On Wednesday, February 13, 2019 at 9:33:48 AM UTC+3, Buster Neece wrote: > > Hello PHP-FIG committee members and

Re: Proposal idea: Feed Parser Interfaces

Hello Gabriel, Thanks for proposal but overall it doesn't sound like Feed Parsing is common enough task and that there's a need for parsers to be inter-operable. If you have examples of different parsers and the need to exchange them or build re-usable components around them, feel free to discu

Re: localization interface?

Hello Oscar, If you need some expertise, I can be part of the working group. The document is a good start but there are some controversial and incorrect parts: 1. The message argument description should not specify that it is the text to translate. In fact, it is an ID to find the translation

Re: localization interface?

I think I must explain why I propose adding parameters. It is because choosing a message by its ID is implemented differently in, for instance, gettext and ICU. In ICU it's a single message including all the variants in it so items number isn't required to get the message by its ID. For gettext

Re: localization interface?

Yes, the tool is necessary as well as fallbacks mechanics. We have all that in Yii and I can not imagine working with translations without these extra tools. Extracting translations is not that complex btw. I don't think that sticking to gettext is a good idea. ICU/intl is far superior in flexib

Re: localization interface?

ong time ago and old messages are > removed due limit free plan. > > > > > > > > > El 1 abr 2019, a las 13:40, 'Alexander Makarov' via PHP Framework > Interoperability Group > escribió: > > Yes, the tool is necessary as well as fallbacks mech

Re: localization interface?

unformatted > messages in each language (intl extension does not provide this feature, > AFAIK) > > > > > > El 2 abr 2019, a las 18:33, 'Alexander Makarov' via PHP Framework > Interoperability Group > escribió: > > That won't work for intl/ICU: >

Re: localization interface?

;> ``` >> >> Here, the translator returns the message that can be in any language >> (english, spanish, italian, etc) and the formatter is what execute >> MessageFormatter->format() internally. >> >> Of course, if you only need english, you may need only the f

Re: localization interface?

gt; parameters different than a number of items. >> >> Can you provide an example of this? >> >> If you prefer to create a different proposal to illustrate your vision, >> it would be clearer to me. >> >> El 2 abr 2019, a las 19:49, 'Alexander Makarov&#

Re: localization interface?

Done: https://github.com/psr-i18n-wg/message-translation/blob/master/message-translation-draft.md About experience Larry mentioned: 1. I'm maintaining Yii i18n/L10N layer. 2. Had experience with Android. 3. Native Russian speaker so know about complicated plurals. On Saturday, March 30, 2019 at

Re: PSR-12 "closing brace of control structure" clarification

> So the question is: why am I allowed to add blank lines to indicate related blocks of code inside switch statements, but explicitly forbidden to do that inside if / elseif / else statements (and probably try / catch / finally, didn't check what phpcs has to say about these)? You are allowed t

Re: PSR-12 "closing brace of control structure" clarification

https://github.com/php-fig/fig-standards/pull/1164 On Monday, April 15, 2019 at 7:09:25 PM UTC+3, alexey...@gmail.com wrote: > > Hi Alexander, > > > You are allowed to separate related blocks of code inside if/elseif/else: > > Yes, but block2 in your example MUST be stuck to unrelated elseif, if o

Re: PSR-12 "closing brace of control structure" clarification

Readability won't be changed much. That is original code: ▮▮ (▮▮(▮▮▮ ▮▮▮ ▮ ▮)) { (▮▮ ▮▮ ▮▮ ( ▮ ▮▮ ▮)); ▮(▮); } ▮▮ (▮▮(

Re: PSR-12 "closing brace of control structure" clarification

Well, maybe. It's widely used in Java so I've got used to it years ago. On Thursday, April 18, 2019 at 3:26:30 PM UTC+3, Robert Korulczyk wrote: > > > As the way to improve the code, it's possible: > > > > switch (true) { > > case preg_match(Token::REGEX_OPERATOR, $this->code, $match, null,

Re: PSR-12 "closing brace of control structure" clarification

Readability-wise using same braces style as we're using for classes and methods would be beneficial for control structures i.e. if ($foo) { doFoo(); } elseif ($bar) { doBar(); } else { doSomethingElse(); } Clear code blocks, vertically aligned braces. You are right that this particu

Re: [PSR-12] Arrow Functions

What rules would you like to propose for arrow functions? On Monday, May 6, 2019 at 6:54:38 PM UTC+4, Joseph Levine wrote: > > Arrow functions are going to be part of PHP 7.4, and I think it's a good > idea to add some guidance now. > > Is it too late since PSR-12 is in review? > > How can I help

Re: [VOTE] Core Committee Election

Yii: - Larry Garfield https://groups.google.com/d/topic/php-fig/HqtrPuUI_YQ/discussion - Matthew Weier O'Phinney https://groups.google.com/d/topic/php-fig/PAnOZqE4QiQ/discussion - Beau Simensen https://groups.google.com/d/topic/php-fig/v1cPGmMT430/discussion - Benni Mack https://groups.goo

[PSR-19] Allow FQSEN in @link

Currently in @see tag FQSEN is allowed: https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#512-see but it's not allowed in @link https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#56-link so there's no way to reference a class in the descr

Re: PSR-19. inline @see tag

Need that as well. On Thursday, April 18, 2019 at 10:30:53 PM UTC+3, Google user wrote: > > in phpdocumentor's phpdoc documentation it's stated that @see tag does > have inline syntax: > >> Syntax >> @see [URI | FQSEN] [] >> or inline >> {@see [URI | FQSEN] []} >> http://docs.phpdoc.org/reference

Re: [PSR-19] Allow FQSEN in @link

Yes. We need both structural element links and regular links in the description. Thanks for the link to the thread. That is exactly what we need. On Wednesday, May 15, 2019 at 6:27:50 PM UTC+3, Google user wrote: > > why at all do you want to use the @link tag and don't want to use @see tag? > >

Re: [PSR-12] / PR for small updates.

Thank you! On Tuesday, August 13, 2019 at 11:44:01 AM UTC+3, William Pinaud wrote: > > Hey there, sorry to kick in out of nowhere, but I just thought I could do > a little regarding PSR-12. > > Not really willing to change its contents, I do like it in general, but > I'm usually rather... Meticu

Re: [VOTE][PROJECTS][BYLAW] PSR evolution

+1 from Yii framework. On Monday, November 11, 2019 at 12:49:12 PM UTC+3, Alessandro Lai wrote: > > Hello everyone, > after a long review phase of my PR and multiple fixes and amendments, I > think it's now ready: > > https://github.com/php-fig/fig-standards/pull/1195 > > The PR adds a new docum

Re: Issue tracking

In this mailing list. On Sunday, January 5, 2020 at 7:55:37 PM UTC+3, Philippe Cloutier wrote: > > Hello Alessandro, > > Le vendredi 3 janvier 2020 16:36:38 UTC-5, Alessandro Lai a écrit : >> >> Please feel free to open a PR to fix that then! >> > > Thanks, but the problem is that due to this very

Re: [PSR-19] Tag for "exported" variables?

That's valid use case for PHP templates and I don't think there's currently a tag for the purpose. On Tuesday, December 31, 2019 at 8:11:03 PM UTC+3, Michele Locati wrote: > > Let's assume this condition: > > - we have a PHP file that defines some variables, but don't actually "use" > them > > -

Re: [PSR-12] Be explicit about whitespaces between empty code block, i.e. curly brackets without any code

How about rules in section 5? - The body MUST be on the next line after the opening brace - The closing brace MUST be on the next line after the body On Monday, January 27, 2020 at 3:27:02 PM UTC+3, Michael Voříšek wrote: > > While following PSR-12 implementation on PHP-CS-Fixer, a comment indic

Re: [VOTE][Projects] TYPO3 Membership vote

+1 from Yii. -- 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 view this discussion on the web vi

Re: "type casting" is a language construct?

Yes, I'd categorize it as a language construct. On Thursday, November 5, 2020 at 11:56:15 PM UTC+3 antonf...@gmail.com wrote: > "Type casting" syntax: "(...) $var" where "..." is php type. > How to categorize the typing? It's language construct or what is this? > -- You received this message

Re: [VOTE][Projects] Bylaw CS update

+1 from Yii framework. On Friday, April 2, 2021 at 7:31:06 PM UTC+3 ni...@niden.net wrote: > +1 > > Phalcon Framework > > On Wednesday, March 31, 2021 at 3:16:33 AM UTC-4 alessand...@gmail.com > wrote: > >> >> Hello everyone, >> this my seem a small formality, but we need a vote for a small byla

Re: [VOTE][CC] AzuraCast Membership vote

+1 On Sunday, August 1, 2021 at 10:15:16 PM UTC+3 woody...@gmail.com wrote: > +1 > > Sent from my iPhone > > On Jul 31, 2021, at 10:05 AM, Vincent de Lau wrote: > > This thread is to collect votes on the AzuraCast Membership vote. > > > > Details: > - membership request: > https://groups.goog

Re: [VOTE][Projects] AzuraCast Membership vote

+1 On Saturday, July 31, 2021 at 6:08:34 PM UTC+3 Michelle Sanver wrote: > +1 > > Hugs, > Michelle > On 31 Jul 2021, 17:05 +0200, Vincent de Lau , wrote: > > This thread is to collect votes on the AzuraCast Membership vote. > > Details: > - membership request: > https://groups.google.com/g/php-

Re: [PSR-12] Proposal for a @generated tag

That sounds like a candidate for PSR-5, not for PSR-12. On Tuesday, August 10, 2021 at 7:05:01 PM UTC+3 ezimuel wrote: > Hi, > > While working with generated PHP files, I noticed we don't have a specific > phpDoc tag to inform us that a file/class/function has been generated. > > Right now, I'm

Re: [VOTE][Projects] Bylaw change: introduce PHP Evolving Recommendations (PERs)

+1 from Yii. Good one. On Tuesday, September 7, 2021 at 8:07:41 PM UTC+3 vin...@delau.nl wrote: > This is the voting thread for the Project Representativesonly. There is a > separate thread for the Core Committee > > Larry Garfield has created a proposal for a change to the bylaws to > introduc

Re: Localisation Pre-Draft PSR Request For Participants

I'd like to join. Left some comments in the google doc. Hope these will be useful. On Friday, October 29, 2021 at 4:11:27 PM UTC+3 navarr@gmail.com wrote: > Hey all! > > Some interest in a Localization PSR from the community has recently come > about - and I thought "this is something I car

[Nomination][CC] Navarr Barnier

As Yii framework representative I nominate Navarr Barnier for the position of Core Committee member. Navarr proved to be interested in new PSRs and is willing to drive PSR-21 forward in a very active manner. I think he is a good match for this role in PHP-FIG. -- You received this message bec

[Nomination][CC] Korvin Szanto

Korvin is a core commitee member since 2016. In the past he helped getting PSR-12 and PSR-11 done and overall moved the group to the right direction. His term ends soon so as a representative of Yii framework, I'd like to re-nominte him for the core commitee position. -- You received this mess

Re: [VOTE][WG] Coding Style 1.0.0 Readiness Vote

+1 On Thursday, May 19, 2022 at 11:35:07 PM UTC+3 Ken Guest wrote: > +1 > > On Thu, 19 May 2022, 18:08 Woody Gilk, wrote: > >> +1 >> -- >> Woody Gilk >> https://www.shadowhand.com >> >> >> On Thu, May 19, 2022 at 11:21 AM Korvin Szanto >> wrote: >> >>> Hi Everyone, >>> The Coding Style PER is

Re: [Internals][ELECTIONS] Request for Nominations

I'll renomiate Korvin Szanto if he's willing to. Also I nominate Larry Garfield. On Friday, February 9, 2024 at 5:34:23 PM UTC+3 Chuck Burgess wrote: > I'll renominate Ken. > CRB > > On Fri, Feb 9, 2024, 07:57 Ken Guest wrote: > >> I would like to serve another term as a member of the Core Comm

Re: Service Provider PSR: rebooting the proposal

Reading https://github.com/container-interop/service-provider/issues/71, and it makes perfect sense to me to reboot the WG. Something great might come out of it. On Monday, March 25, 2024 at 12:46:47 AM UTC+3 Ken Guest wrote: > This all makes sense in at least general terms, and having a PSR to

Re: [Internal] [Discussion] Paul M Jones

I'm trying to stay out of politics but since silence could be considered an agreement I'd voice my opinion. 1. Expulsion would not help in any way and is pointless. The only voting member extra ability is to be able to vote as a representative of the project so it has nothing to do with a perso

Switch to forum software?

Mailing list has many issues: 1. Really hard to read conversations since everything is cited and different mail clients are doing it differently. 2. Everything is a big sticky pile of mud. In a forum we'll be able to have separate categories for separate proposals so it will be **much** easier t

Re: Switch to forum software?

On Sunday, June 26, 2016 at 11:30:55 AM UTC+3, Alessandro Pellizzari wrote: > > On Sat, 25 Jun 2016 07:59:16 -0700 (PDT) > "'Alexander Makarov' via PHP Framework Interoperability Group" > > wrote: > > > Mailing list has many issues: > &g

Re: Switch to forum software?

On Sunday, June 26, 2016 at 2:36:01 PM UTC+3, Andreas Heigl wrote: > > Hi Alexander. > > Perhaps you have seen the thread "[IDEA] Transition Google Groups to > Slack/Gitter/Discourse" ( > https://groups.google.com/forum/#!msg/php-fig/uN0EykvQkAA/rCHFHLvRAwAJ). > No, I did not. Was at vacation

Re: [Internal] [Discussion] Paul M Jones

Well said. Absolutely agree. Anyway, revoking vote is irrelevant. What other options are there? If it were forum engine, I'd proposed official rules that state that "Personal offense isn't tolerated. Each occurrence results in ban for a week. X repeating occurrences results in permanent ban no

Re: The CLI interface PSR brainstorm

Sounds fine to me. We have a CLI wrapper in Yii so I can provide some input for questions raised. On Monday, June 27, 2016 at 10:57:46 AM UTC+3, Dracony wrote: > > A year or maybe two ago I proposed a PSR for "tasks", that would allow > easier chaining of common things like e.g. migrating a data

Re: I resign

Thanks for all the work done on PSR-5. Hope to see you back one day. On Sunday, June 26, 2016 at 11:05:49 PM UTC+3, Mike van Riel wrote: > > Dear all, > > In these last few days I have done a fair bit of soul-searching, both the > kind where you try to reflect how you sound to others and on how

Re: Switch to forum software?

I don't see any tags in Google Groups web UI... On Monday, June 27, 2016 at 12:32:51 PM UTC+3, Alessandro Pellizzari wrote: > > On 26/06/2016 16:21, Robert Korulczyk wrote: > > > How can I ignore all (including future) topics relating to politics or > PSRs, which I'm not interested? If your answ

Re: Switch to forum software?

Let's start with voting. I've coded about 40% of it yesterday evening... On Monday, June 27, 2016 at 3:26:13 PM UTC+3, Stefano Torresi wrote: > > This discussion a bit of a beating on a dead horse. > This proposal has been brought up time and time again, and people > participating in it have been

Re: Switch to forum software?

> at the same time as a coded voting system that we've been working on Wait, so you're implementing it? I've started it as well :) If you're on it, I'll spend time on something else... On Tuesday, July 12, 2016 at 1:57:26 PM UTC+3, Michael Cullum wrote: > > Hi all, > > We [the secretaries] have

Re: [VOTE] Membership Application: pimcore

+1 Yii framework. On Monday, July 18, 2016 at 5:01:00 PM UTC+3, Lukas Kahwe Smith wrote: > > Aloha, > > So given that there didn’t see to be any opposition (then again also no > support by-side me) for the adoption of pimcore in the original thread > requesting for addition to the member list,

Re: [Vote] Require Aura project to replace its representative

-1 from Yii. On Friday, July 29, 2016 at 2:56:52 AM UTC+3, Samantha Quiñones wrote: > > All, > > The discussion period having concluded, I am now opening a vote on the > matter of the proposal to require the Aura project to name a new voting > representative. > > The discussion thread is avail

Re: On the Interoperability of Cryptographic Components -or- Stop Writing In-House Cryptography Features

Hello Scott, While it's important, I think it's out of scope of the group. Each project decides individually. On Saturday, July 30, 2016 at 8:13:37 PM UTC+3, Scott Arciszewski wrote: > > Hi FIG, > > I've noticed that a lot of frameworks and platforms provide their own > cryptography features, a

Re: On the Interoperability of Cryptographic Components -or- Stop Writing In-House Cryptography Features

FIG always focused on interoperability i.e. multiple implementations, same interface. What Scott proposed makes sense but doesn't fit into "multiple implementations". On Sunday, July 31, 2016 at 1:10:01 PM UTC+3, Alessandro Lai wrote: > > Why should it be out of scope? A PSR is a reccomandation,

[PSR-12] Enforce short type keywords

For the PSR-12 coding standard I've made a change that forces using short form of type keywords i.e. bool instead of boolean, int instead of integer etc.: https://github.com/php-fig/fig-standards/commit/a77993bdf52eb6d5cb9ca37dba3af4df9e3b909c As Michael Cullum pointed out, I was too fast and i

[PSR-12] Do not enforce blank line after

The change is part of https://github.com/php-fig/fig-standards/commit/50a3d046baa5143546dc95bf5930d3523f56be6a, made after discussion in a pull request: https://github.com/php-fig/fig-standards/pull/730#discussion_r57308607 and getting some stats on current state of things. It's about blank l

Re: Status of PSR-12 survey

While I agree that it could be a good idea to wait till PHP7 adoption and usage rate will raise, I think that it would be better if PSR-12 current state (master) will reflect what people prefer or like even if they aren't using PHP7 yet. It's definitely better alternative than not being backed u

Re: Usage of our git (php-fig/fig-standards) repository

That's me who triggered it :) Michael, maybe it could be added to workflow docs? What do you think? On Sunday, July 31, 2016 at 8:49:33 PM UTC+3, Michael Cullum wrote: > > Hi all, > > Just a quick note regarding the main fig standards repository. It should > never be pushed directly to, everythi

Re: Status of PSR-12 survey

We hear you. We'll collect as much data as we can. Then will build a PSR based on the data collected but not only the data collected. On Monday, August 1, 2016 at 5:51:19 PM UTC+3, Larry Garfield wrote: > > On 08/01/2016 01:32 AM, Andrew Carter wrote: > > Some projects still don't use PSR-2 beca

Re: [PSR-12] Enforce short type keywords

PSR-5 scope is phpDoc exclusively. It cannot affect types used for typecasting. On Monday, August 1, 2016 at 6:32:45 PM UTC+3, Larry Garfield wrote: > > On 07/31/2016 02:03 PM, 'Alexander Makarov' via PHP Framework > Interoperability Group wrote: > > For the PSR-12 co

Re: [PSR-12] Enforce short type keywords

t reason enough > on its own). > > Many thanks, > Michael Cullum > (Not speaking as Secretary but as Former PSR-12 Editor inline with > declared conflicts of interest) > > On 2 Aug 2016 9:10 a.m., "'Alexander Makarov' via PHP Framework > Interoperability Gro

Re: [PSR-12] Enforce short type keywords

n be neutral > on the change. > > -- > Michael C > > On 2 August 2016 at 14:24, 'Alexander Makarov' via PHP Framework > Interoperability Group > wrote: > >> So would it be OK if we won't touch documentation i.e. remove "in both >> code and doc

Re: Status of PSR-12 survey

We won't keep survey data private for sure. It will be in the meta. PSR-1 and PSR-2 went far beyond FIG-member projects so I guess PSR-12 could be alike in terms of scope. On Wednesday, August 3, 2016 at 5:34:28 PM UTC+3, pmjones wrote: > > > > On Aug 3, 2016, at 09:07, glen-84 > > wrote: > >

Re: [PSR-7] Opinions requested on potential patch

Looks like a fix to me. On Wednesday, August 3, 2016 at 9:54:13 PM UTC+3, Matthew Weier O'Phinney wrote: > > Hi! > > I've been reviewing pull requests against the http-message repository, and > had > given my thumbs-up to the following: > > - https://github.com/php-fig/http-message/pull/50 >

Re: [PSR-12] Do not enforce blank line after

Considering the number of the project which do not have blank line and the fact that it's much higher number than number projects that do have blank line, I think it should be two questions: 1. Should it be enforced at all? 2. Should we enforce blank line or should we enforce no blank line? On

Re: Switch to forum software?

That actually may work very well and has many pros. Cons... none? On Saturday, August 6, 2016 at 6:10:25 PM UTC+3, pmjones wrote: > > > > On Aug 6, 2016, at 10:06, Amanda Folson > wrote: > > > > Some people want a web UI, some people want a mailing list...may as well > use GitHub issues so peo

Re: [VOTE] Secretary Election August 2016

Votes for Yii framework: 1. Jonathan Reinink 2. Paul 'PMJ' Jones 3. Matthew 'Matt' Trask 4. Samantha Quiñones 5. Phil Sturgeon On Saturday, August 13, 2016 at 1:24:40 AM UTC+3, Michael Cullum wrote: > > Hi all, > > So for those unaware, it's that time again. Every 8 months a secretary's > term e

Re: Questions on some coding styles

Indeed these aren't addressed in PSR-2. There's PSR-12 in the works . First two cases aren't addressed as well so I've created issue for these: - https://github.com/cs-extended/fig-standards/issues/37

Re: [VOTE] PSR-6 Errata

- 1 from Yii framework. It's very significant backwards compatibility change. On Friday, August 19, 2016 at 9:44:01 PM UTC+3, Larry Garfield wrote: > > I hereby open a vote for the following Errata for PSR-6: > > https://github.com/php-fig/fig-standards/pull/787 > > Basically, it's a vote to me

[FIG 3.0] Need clarifications about core committee

Voting on FIG 3.0 started. I've read diff of the changes (huge one), TLDR at medium and searched ML but haven't found answers to some questions. Please help me find the answers. Thanks! 1. What's the reason to limiting core committee to 12 members? To me it looks wrong that 2. Why 12 exactly?

Re: [FIG 3.0] Need clarifications about core committee

passed multiple stages. *// Just realized I haven't finished 2nd sentence :) Please ignore "To me it looks wrong that".* On Monday, August 22, 2016 at 1:12:42 AM UTC+3, Chris Tankersley wrote: > > > > On Sunday, August 21, 2016, 'Alexander Makarov'

Re: [VOTE] "FIG 3.0" Bylaw amendments

-1 from Yii. // Because of exactly 12 core committee members (discussed in a separate thread) and overall lack of attention/discussion from the group before the vote. On Friday, August 19, 2016 at 9:39:19 PM UTC+3, Larry Garfield wrote: > > A few days later than planned, but I am hereby opening

Re: [FIG 3.0] Need clarifications about core committee

Thanks for more clarifications. What about 12 vs 13 and even number of votes issue? On Monday, August 22, 2016 at 8:11:27 PM UTC+3, Larry Garfield wrote: > > On 08/21/2016 04:30 PM, 'Alexander Makarov' via PHP Framework > Interoperability Group wrote: > > Voting on F

Re: [FIG 3.0] Need clarifications about core committee

Great. Then it makes sense to me. The diff is quite big and info is a bit scattered there. I guess that's why there are negative votes on topic. On Monday, August 22, 2016 at 10:56:50 PM UTC+3, Larry Garfield wrote: > > On 08/22/2016 01:37 PM, Chris Tankersley wrote: > > > On Mon, Aug 22, 2016 at

Re: Questions on some coding styles

Then https://groups.google.com/forum/#!topic/php-fig/kIqR-7WI690 should be OK, right? It's was the new rule which was not present in PSR-2 and isn't connected with new PHP functionality. On Monday, August 22, 2016 at 9:32:31 PM UTC+3, Michael Cullum wrote: > > If this was discussed for PSR-1/2 t

Re: [FIG 3.0] Need clarifications about core committee

Well, clarity of the document. It takes time to find what you need so maybe wording or structure could be improved for better comprehension, cross-linking introduced etc. On Wednesday, August 24, 2016 at 1:07:40 AM UTC+3, Alessandro Lai wrote: > > Well, the vote has now been canceled. I've just

Re: [FIG 3.0] Need clarifications about core committee

gueness, which in prose does tend to > lead to verbosity. To me it still reads fairly well, but as the author I > am of course biased on that front. :-) > > --Larry Garfield > > On 08/24/2016 05:27 AM, 'Alexander Makarov' via PHP Framework > Interoperability Group

Re: [VOTE] [Bylaw Amendment] Do not require interface suffix on future PSR Interfaces

-1 from Yii. On Sunday, September 4, 2016 at 7:26:50 PM UTC+3, Michael Cullum wrote: > > Hi all, > > The PSR-11 Editors have requested we open this vote for them as they are > unable to do so not being voting members. > > *Status Quo:* The bylaw states that all interfaces in PSRs published by >

Re: [VOTE] "FIG 3.0" Bylaw amendments (Take 2)

+1 from Yii. On Saturday, September 17, 2016 at 2:14:08 AM UTC+3, Larry Garfield wrote: > > I hereby open a vote for the following bylaw changes, colloquially known > as "FIG 3.0". I'm fairly certain anything that needs to be said has > been said by now by all parties. > > https://github.com/p

Re: [Important] [Internals] All projects must declare intention to remain members

Yii framework remains. On Monday, October 3, 2016 at 2:44:02 AM UTC+3, Michael Cullum wrote: > > As per the FIG 3.0 bylaws, all member projects must, between the 1st > October and 31st October, declare they wish to remain a member project of > the FIG. If you don't wish to remain, then it would

  1   2   >