Re: [Internal] [Discussion] Paul M Jones

Hey list, I too was one of the attendees of the FIG meeting at Phpday2016 like Stefano. I'm not a member, but I'm following the FIG closely since nearly two years ago, and I do share the opinion that moved this topic to the surface. I must state, to start with, that I'm opposed to an

Re: [Internal] [Discussion] Paul M Jones

Your point is clear enough, but I think that I have an answer to your "So why here, why now?" question: Because this is not Reddit, this is not a casual forum. We are here to work together, to discuss together and to find a common ground to get PSR done. Paul is greatly involved in this work,

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

Why should it be out of scope? A PSR is a reccomandation, and advocating this kind of security best practice is a good thing 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

Re: [Nomination] FIG Secretary: Paul M. Jones

Also, there is the point of consistency by the FIG itself. If in the past projects have been barred because of this impasse, and no bylaw exists about it, why should Aura be treated otherwise? Last bur not least, I would like to point out that this nomination itself created a very strange

Re: Alternative to FIG 3.0: Encourage *-interop projects

This is a really nice proposal. I also think that this does not solve anyway the issues of the FIG itself; maybe the best option could be to push for both approaches? Nothing in the FIG 3.0 proposal forbids that! In fact, I think that the FIG 3.0 modification are good anyway, and that the

Re: [REVIEW] PSR-11 Container Interface

I really like this proposal y Nikolas, especially the part about the SHOULD NOT use the exception for control flow... Il giorno domenica 15 gennaio 2017 08:48:15 UTC+1, Nicolas Grekas ha scritto: > > Hi David, > > let's drop any distinction between "entry not found" and "dependency >>

Re: [FIG 3.0] Need clarifications about core committee

Yeah, the point is exactely that. The core committee doesn't need to be experts on the field, they can relay that to the WG. They can (and must) however reject a PSR if they think that the WG ignored or didn't listen to experts or big players in the context of the PSR. Il giorno lunedì 22

Re: [FIG 3.0] Need clarifications about core committee

ol.md > > -- > Michael Cullum > FIG Secretary > > On 24 August 2016 at 22:26, Alessandro Lai <alessand...@gmail.com > > wrote: > >> Larry, it think that the part about vote rounding is not clear enough; >> it's understandable through the examples, but the rule

Re: Resigning My Position ...

I totally agree with Jason. Also, it may conflict with the fact that the PSRs are released under MIT license. Il giorno lunedì 12 settembre 2016 12:19:05 UTC+2, Jason Judge ha scritto: > > On Friday, 9 September 2016 15:53:28 UTC+1, pmjones wrote: >> >> Hi all, >> >> I am resigning my position

[PRE-VOTE DISCUSSION] Withdraw PSR-8

Personally, I would agree on leaving it there. Anyhow, the FIG 3.0 vote is for coming up, I would wait it before doing anything about it: having those bylaws active would smooth this process a lot. -- You received this message because you are subscribed to the Google Groups "PHP Framework

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

Good job! I really like the edits on the opening statement, it's more short while retaining its meaning. -- 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,

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

I think that it's meant to advocate the whole of FIG, not a single PSR or a solution to some issue. Il giorno giovedì 15 settembre 2016 15:40:10 UTC+2, Glenn Eggleton ha scritto: > > From the 3.0 Docs. >

Re: [FIG 3.0] Need clarifications about core committee

Well, the vote has now been canceled. I've just now finished reading again the full diff, and I've found clarifications about possible tie votes: majority must be +1 with 50%: https://github.com/php-fig/fig-standards/pull/752/files#diff-a7e6254aa839471064951898e0ebb021R17 So basically no tie

Re: [FIG 3.0] Need clarifications about core committee

So Larry, this also addresses the issue of the (12) even number of the core committee? Since votes requires always 2/3, no tie is possible? -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group

Re: [FIG 3.0] Need clarifications about core committee

'Alexander Makarov' via PHP Framework > Interoperability Group wrote: > > 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,

Re: [PSR-11] Review of the delegate lookup feature

I agree with Alessandro. Since this seems a pretty controversial point, I would drop it, in favor of continuing the discussion into a new separate PSR, or maybe the "add stuff in the container" PSR. PSR-11 is just a stepping stone for everything in this area, so I would prefer to drop it and

Re: PSR Log - Why no NULL default value for LoggerAwareInterface and LoggerAwareTrait

You shouldn't make the logger optional, IMHO. If you want, there is a NullLogger implementation that you can use in edge cases (or during tests). Il giorno giovedì 3 novembre 2016 14:51:01 UTC+1, n.y...@gmx.at ha scritto: > > Thank your for this fast answer. As i wrote i am aware that this was

Re: [REVIEW] PSR-11 Container Interface

I don't think that the fact that PSR-11 is limited to a get is a reason to worry. In my opinion we should see this standard as a stepping stone for everything about containers. Basically, I foresee in the feature various other container-related PSR, and PSR-11 will just be a prerequisite,

Re: [PSR-11] Review of the delegate lookup feature

Kudos to you for stepping down on your proposal and to have listened to feedback! The fact that this PR hilights how much text is removed from the PSR underlines how much the delegate lookup needs a separate PSR. I think it will be better on the long run, also because you will be able to

Re: First Core Committee Members!

Congratulations to everyone that got elected, PSR-8 all around!! Il giorno sabato 24 dicembre 2016 21:36:42 UTC+1, Michael Cullum ha scritto: > > Hi all, > > I'm happy to be able to announce the make-up of the new, and first, PHP > FIG Core Committee. > > *Top Four Candidates (Until April

Re: PSR for HTTP clients

Very good suggestions. Also, it's very pleasant to see a PSR pushed this way and backed from the start by a working lib and all the interestend players. Really good job! Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto: > > On 07/07/2017 12:20 PM, Tobias Nyholm wrote: >

Re: UX/UI designer || Denver , CO

I already marked them as spam on the G-Groups interface, maybe everyone can do it so the secretaries (and Google's spam filter) can take care of it! Il giorno giovedì 29 giugno 2017 17:05:34 UTC+2, Lewis ha scritto: > > Can someone stop this ass posting nonsense all over the mailing list? > > On

Re: PSR-12: Order of сonstants, methods and properties definitions

I agree that a sequence of constants-properties-methods is ok and expected. But apart of requiring the constructor as the first declared method, I'm against a "MUST" keyword for the remaining stuff. We can maybe suggest and ordering of this kind, but for the most part the order shouldn't be

Re: Survey: Naming things

I like Larry's reasoning about the problems that a 2.0 versioning would bring up. But what about the reverse side? How could a package signal in it's deps that is compatible with one or the either version (or both)? Maybe we can discuss this at length this weekend @ PHPDay.. Il giorno lunedì

Re: [PSR-6][Errata] expiresAt() missing parameter type, take 2

I think that in this discussion we could incorporate how we want to proceed in terms of future approaches to this standard. Since, as you said in the other thread, now PHP 5.5+ can be safely assumed, we can think of "upgrading" PSR-6 to a better typehint, but how? I still think that this

Re: [Secretary nomitation] Alessandro Lai

, please, do it here! Il giorno lunedì 25 settembre 2017 10:34:34 UTC+2, Matteo Beccati ha scritto: > > Hi everyone, > > I hereby nominate Alessandro Lai (alessand...@gmail.com ) > for the > position of FIG Secretary. > > Alessandro is one of the coordinators of the Mi

Re: Proposal for extended coding style guide

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 normally applied just to the symbol at the immediate right of it... Il giorno lunedì 23 ottobre 2017 08:56:35

Re: Proposal for RDF interfaces

Hello! As I've already stated on the PR (https://github.com/php-fig/fig-standards/pull/958#pullrequestreview-77724961) you should follow the PSR workflow and form a working group with a CC member as a sponsor. Feel free to use this thread as a starting point! Il giorno mercoledì 8 novembre

Re: Proposal for RDF interfaces

sandro, > > thanks for the reply. I have a hard time finding a list of all Core > Committee members (only found http://www.php-fig.org/members/ at the > moment). And what would you suggest to reach them/ask them directly? > > Regards > Konrad > > On Monday, November 20, 2017

New Secretaries

Thank you all for your support and for your votes! I didn't expect to receive all those first votes.. I too cannot wait to dive in and help this group move forward! -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To

PHPDay 2018 meeting recap

Hello everyone! I'm back from the PHPDay 2018 conference, where we held an (un)official PHP-FIG meeting in the unconference track Saturday afternoon. https://twitter.com/jflamman/status/995310647826149377 I will try to recap what was discussed here. The main topic was going through the

Re: [PSR-12] Moving Back to DRAFT Status

The PSR will follow its normal course: the WG has already discussed a few thing that are needed to be fixed, and appropriate PRs will be submitted. After that, a new review vote will be held, and the PSR will go back into review phase. Il giorno mercoledì 16 maggio 2018 05:42:24 UTC+2, Adrien

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

We discussed that as WG, and we concluded that having a comment in the same line of a closing bracket can hinder readability, due to the fact that the closing bracket could not be seen; also, not only IDE but basically any code editor (even vim) have bracket highlighting. Il giorno mercoledì

Re: New representative for Magento

Hi Mark, and thank you; also, welcome Anton! I've updated the personnel list, can you confirm to me that that is correct, so I can push it to the official site? Il giorno martedì 15 maggio 2018 19:04:18 UTC+2, Ben Marks ha scritto: > > Hi all, > > Effective immediately the representative for

Re: [PSR-5] Working Group Formation

The sponsor, which in this case should be Michael, has to call the vote on that. When the vote passes, the WG is officially formed. In any case, that shouldn't stop you from working on the draft anyway, as the content of it shouldn't matter in regard of the vote, which is only about the

Re: [Secretary nomination] Mark Railton

Nomination recorded, thanks Joe and Mark. Il giorno venerdì 5 gennaio 2018 21:24:00 UTC+1, Mark Railton ha scritto: > > Thank you for the nomination Joe, I'm more than willing to accept it. > > For those that may not know me, you can find me on markrailton.com and on > twitter/github as railto.

Re: Console Psr

Time may not be important, but the fact that there is a challenge and response between the user and the application may change a lot the type of interaction. I hardly see a way to standardize this kind of stuff between a console and an HTTP part of an app. Il giorno giovedì 11 gennaio 2018

Re: [Internals] Secretary & 4 Core Committee Nominations Open

Nomination registered, thanks to you both! Il giorno mercoledì 10 gennaio 2018 17:43:58 UTC+1, Chris Tankersley ha scritto: > > Thanks Ben :) I accept his nomination, and look forward to hopefully > continuing my work as a CC member. > > -Chris > > On Tue, Jan 9, 2018 at 8:05 AM, Ben Marks

Re: [Secretary nomination] Robert Parker

Hi Robert, welcome! Thanks to you both, nomination is registered! Il giorno giovedì 11 gennaio 2018 01:00:45 UTC+1, rparker@kodama.design ha scritto: > > Thank you Korvin for the nomination. I accept it. > > I have worked as a Drupal 7 developer at a web agency for two years and as > a

Re: [CC nomination] Stefano Torresi

Nomination registered, thanks! Il giorno mercoledì 10 gennaio 2018 21:59:40 UTC+1, Stefano Torresi ha scritto: > > Thanks Matthew! Needless to say I gladly accept the nomination! > > Il Mer 10 Gen 2018, 15:32 Matthew Weier O'Phinney < > mweierophin...@gmail.com> ha scritto: > >> I hereby

Re: [CC nomination] Michael Cullum

Nomination registered, thanks to you both! Il giorno mercoledì 10 gennaio 2018 18:30:42 UTC+1, Michael Cullum ha scritto: > > Thanks for the nomination Alexander, I'm happy to accept. > > I've been a FIG Secretary for 2 years now and I think it's time for > someone else to step into those

Re: [Internals] Secretary & 4 Core Committee Nominations Open

(2016-01-31 - 2018-01-31): - Michael Cullum (@michaelcullumuk) Site will be update once https://github.com/php-fig/fig-standards/pull/957 and https://github.com/php-fig/php-fig.github.com/pull/230 will be merged. Il giorno martedì 2 gennaio 2018 00:11:02 UTC+1, Alessandro Lai ha scritto: > &

[VOTE][Internals] Secretary election

hase I will be announcing the results, and all the newly elected (both CC members and secretary) on the 28th, as announced before. Thanks! Alessandro Lai PHP-FIG Secretary [1]: STV User-friendly Explanation https://www.youtube.com/watch?v=l8XOZJkozfI [2]: https://en.wikipedia.or

Re: [VOTE][PSR-6][Errata] DateTiemInterface handling

Review period was called correctly by Larry two weeks prior: https://groups.google.com/forum/?fromgroups#!topic/php-fig/IXFXHqi5NLo Unfortunately, the reviews came later, so it's up to Larry to decide if he want to stop the vote and address those, or go forward. -- You received this message

Re: There MUST be one use keyword per declaration <-- does this still apply in PHP7

You should take a look at PSR-12, which is in review right now: https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md Il giorno venerdì 2 febbraio 2018 21:05:38 UTC+1, Julian Vidal ha scritto: > > I write my projects using PSR-2 enforced by my IDE

[Internals] Elections results

Hello everyone, this week the elections closed for this month. As stated in the previous thread (https://groups.google.com/forum/#!topic/php-fig/mwjxOFMrMRQ) today, the 28th, it's the day that the newly elected take posts. To recap, those are the results: 4 unopposed nominations, elected as

Re: Working Group for PSR-5

That's great news! As per our bylaws (http://www.php-fig.org/bylaws/psr-workflow/#abandoned), you don't need our approval to go forward, you only need to restart the process from the draft stage. To do that you'll need: - an editor (which you are requesting to be) - a CC sponsor (as you

Re: PSR-11 and Configuration

I completely agree with that. This could be a completely separated PSR that produces an interface for getting configuration values; if frameworks decide to implement both this and PSR-11 interfaces on the same class it's an implementation detail! Il giorno martedì 13 febbraio 2018 02:54:20

Re: The progress of HTTP client

As per our bylaws (see https://www.php-fig.org/bylaws/psr-workflow/#abandoned), abandonment must be explicitly declared either by an abandonment vote, or by a secretary, but with some prerequisites: - missing editor or sponsor for more than 60 days (not the case here) - no activity in 6

[Internals] Secretary & 4 Core Committee Nominations Open

the newly elected will take post. Voting is done through STV, as per our bylaws. For more information please read the bylaws or the FIG 3.0 TL;DR. Thanks! Alessandro Lai PHP-FIG Secretary -- You received this message because you are subscribed to the Google Groups "PHP Framework Interop

Re: [Internals] Secretary & 4 Core Committee Nominations Open

Last but not least, spread the word! Please retweet this: https://twitter.com/phpfig/status/947969054043762689 and actively search people that could be nominated! Il giorno martedì 2 gennaio 2018 00:11:02 UTC+1, Alessandro Lai ha scritto: > > Hi all, > > The nominations for 4 Co

Re: Secretary Elections - Nominations Needed!

mmunity and the development if chosen. Thanks! > > > On Sunday, July 15, 2018 at 10:41:37 PM UTC+5, Dead Lugosi wrote: >> >> Hey y'all, >> >> It is that time again for a vote for who should be filling* 2 secretary >> positions *- the secretary seat currently filled b

[Internal] CC elections result

Hello everyone! Yesterday it was the deadline for the CC elections. Since we have uncontested seats, we decided to go ahead with automatic confirmations. So we have 3 reconfirmed seats: - Cees-Jan Kiewiet - Lukas Kahwe Smith - Samantha Quiñones And one new member, Chuck Burgess, replacing

Re: [Phalcon] Voting member change request

Nikolaos Dimopoulos >> wrote: >> >>> Hello Alessandro, >>> >>> Is now a good time to make this request (since it is August) or do I >>> have to wait for all the secretary nominations etc.? >>> >>> Thanks! >>> >>> On F

Re: Abandoned PSR-5

Hello all! If anyone like you is interested in helping pushing PSR-5 back in the draft stage, please contact Chuck (which is willing to step in as a new Editor) or to us secretaries (me, Mark Railton or Margaret Staples). We need 5 persons (including an editor and a CC sponsor) to build a

Re: Stepping down from CC

Hi Gary, sorry to see you stepping down. As a quick note, your spot can remain vacant up to the next elections in august, since we are (slightly) less than 4 months away, which is the limit for this case in our bylaws:

Re: [PSR-14][Entrance][VOTE]

As all current members of the CC committee have voted, this vote can be considered closed. The vote has passed unanimously! I'll open the PR to change the PSR status immediately. Il giorno lunedì 23 aprile 2018 02:13:41 UTC+2, Samantha Quiñones ha scritto: > > +1 > > (sorry, Larry <3) > > On

Re: [PSR-12] Blank line after trait use import statement

No, multiple blank lines are not allowed in the current spec. Section 3 refers to a SINGLE blank line: "The header of a PHP file may consist of a number of different blocks. If present, each of the blocks below MUST be separated by a single blank line, and MUST NOT contain a blank line."

Re: Please make new pkgist release of PSR-16

Hi Alice, thanks for reminding us of this! I'll try to take care of this ASAP. For reference, she's referring to this commit: https://github.com/php-fig/simple-cache/commit/408d5eafb83c57f6365a3ca330ff23aa4a5fa39b Il giorno lunedì 5 marzo 2018 00:23:44 UTC+1, Alice Wonder ha scritto: > > When

Re: Service provider PSR: discussing the scope

I'm very happy that this is gaining traction, thanks David for spinning this up! Can I suggest you to focus on defining the scope of your proposal? In this way you could start gathering a sponsor and a working group, and start a PSR! Reach out to me or one of the other secretaries if you need

Re: Integration of JS and CSS

Hi Alice, and welcome to this mailing list. I'm sorry but I think you misread the previous response: we're not talking about RPM, but NPM, and Yarn. They are JS-specific package managers, that are designed to resolve exactly what you need. You should also take a look at Symfony WebPack Encore,

Re: [PSR-6][Errata][Review][Take 3][More tags]

The two weeks are just concluded, and no further discussion arose. The only concern raised was from Niklas Keller about the behavior with type declaration and PHP 7.2 allowing to drop that, but I think that's clarified in the discussions too. Larry, it's up to you to push it to a vote! Il

Re: [ACCEPTANCE VOTE][CC] PSR-18 HTTP Client

And I hereby declare the vote closed, as of midnight. With this, PSR-18 is approved with an unanimous vote from the CC! I'll address the relevant PRs this morning; since it was discussed elsewhere, I'll add references to the implementations in the meta doc. Il giorno sabato 27 ottobre 2018

Re: [PSR-12] Additional Thoughts from an outsider

Thank you for you suggestions! For the first one, I've never seen in the wild an usage that would contradict that rule, have you ever? As for the second, it seems pretty reasonable to me, and I've just created a PR: https://github.com/php-fig/fig-standards/pull/1089 Il giorno domenica 30

Re: [PSR-14] Meeting Summary - 2018-09-28

Seems that you really did a great work, and with a really fast pace! Thanks Larry for your effort and your continuous feedback on your group's work! Il giorno venerdì 28 settembre 2018 23:42:14 UTC+2, Larry Garfield ha scritto: > > The only significant topic on the agenda this week was Naming

Re: [ENTRANCE] [VOTE] [CC] PHPDoc & PHPDoc Tags PSRs

I hereby close the vote. All the CC members have voted in unanimity, approving both PSR! PR incoming to our main repo to reflect the new status. Il giorno lunedì 24 settembre 2018 03:54:10 UTC+2, Samantha Quiñones ha scritto: > > Vote 1 (PHPDoc PSR-5): Yes > Vote 2 (PHPDoc Tags PSR-19): Yes >

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

This is the issue traking the implementation on PHPStan: https://github.com/phpstan/phpstan/issues/652 Il giorno sabato 8 dicembre 2018 21:44:14 UTC+1, Chuck Burgess ha scritto: > > I'm thinking this use case will probably need to rely on some kind of > collection/generics syntax. Do we know

Re: Test dependencies in the psr/log package??

Sorry for adding this with so much little notice. I added that since the other one was already present, and that wouldn't change the number of implicit dependency on that package. Obviously not using that class will not trigger any issue, but removing that now would be a BC, so I'm against

Re: [PSR-12] Casting variable section

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: > > if ( (bool) $var === true){ > > } > > // although this might be covered from section about if

Re: [ACCEPTANCE VOTE][CC] PSR-14 Event Dispatcher

Voting is closed with the following result: +1: 10 votes +0: 1 vote Missing: 1 CC member Quorum (11/12) is reached, majority (10/11) too, PSR-14 is approved! Il giorno venerdì 22 marzo 2019 19:33:07 UTC+1, Sara Golemon ha scritto: > > On Sunday, March 10, 2019 at 1:31:50 PM UTC-5, Cees-Jan

[INTERNAL] Core Committee & Secretary nominations open

laws or the FIG 3.0 TL;DR. Thanks! Alessandro Lai PHP-FIG Secretary -- 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 ph

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

Hello Buster, and welcome! Don't worry, this is the correct avenue to push this kind of request. Alexander was just pointing out that not being a project member is not an hindrance to working group participation. If you know someone in the CC or other project members that is willing to sponsor

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

+1 (even if you forgot about me :P) Il giorno lunedì 28 gennaio 2019 18:25:37 UTC+1, Korvin Szanto ha scritto: > > 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

Re: [CC][Nomination] Woody Gilk

Nomination registered, thanks to both of you! Il giorno venerdì 12 aprile 2019 00:43:57 UTC+2, Woody Gilk ha scritto: > > Thank you, Matthew! > > I accept the nomination. > > On Thu, Apr 11, 2019, 16:12 Matthew Weier O'Phinney < > mweierophin...@gmail.com> wrote: > >> I worked closely with Woody

Re: [CC][Nomination] Larry Garfield

Nomination registered, thank you! Il giorno giovedì 11 aprile 2019 19:42:08 UTC+2, Larry Garfield ha scritto: > > Thanks for the vote of confidence, Cees-Jan! > > I hereby accept the nomination. > > -- > Larry Garfield > la...@garfieldtech.com > > On Thu, Apr 11, 2019, at 6:23 PM,

Re: [BYLAW] Proposal: let PSRs evolve with the language

t; We could also talk about a Revision Approval voting protocol, which could > maybe be a shorter version of the corresponding PSR Readiness and > Acceptance, or maybe just use those instead, but I'll leave this particular > issue open because I think is not that crucial right now. >

[BYLAW] Proposal: let PSRs evolve with the language

Hello everyone, I would like to push forward a proposal that is bugging me for so long. Today I read this comment on our GitHub: https://github.com/php-fig/fig-standards/pull/1171#issuecomment-499382349 Larry correctly shot down the last in a long list of small PRs that our approved PSRs had

[Internal] Election results

Hello everyone, I'm happy do announce the results of the now closed elections! For the secretary position, since the nomination was unopposed, Asmir Mustafic gains the seat. As per the Core Committee, I've collected all the votes, with the exception of the last one (sorry), because it came too

Re: [PSR-12] Arrow Functions

We came up with a possible "soft" solution for this issue: we could add to the meta doc that short functions should follow operator + closure syntax requirements. Do you think this is feasible and without edge cases? Il giorno lunedì 6 maggio 2019 16:54:38 UTC+2, Joseph Levine ha scritto: > >

Re: psr 19. current uri standard 3986 instead of obsoleted 2396 DRAFT standard

Thanks for spotting this. Since it seems a straightforward edit, feel free to send a PR to the appropriate documento on GitHub! Il giorno giovedì 18 aprile 2019 21:53:23 UTC+2, Google user ha scritto: > > the description of @see and @link tags in the phpdoc tags psr refers to > the rfc 2396: >

[CC][Nomination] Adam Englander

I would like to nominate Adam Englander for the upcoming CC election. Adam (https://twitter.com/adam_englander) is a longtime PHP developer and speaker, organizer of the Las Vegas PHP UG, and is focused on security. He recently become one of the new maintainers of the Joind.in project

Re: [CC][Nomination] Adam Englander

Nomination registered, thank you. Il giorno martedì 30 aprile 2019 15:19:37 UTC+2, Adam Englander ha scritto: > > I accept the nomination. Thank you Alessandro. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To

[CC][]Nomination] Beau Simensen

I would like to nominate Beau Simensen (@beausimensen) for the incoming CC election. Beau is holding one of the CC spots up for reelection, and he has been vital in the PHP-FIG in the past, in particular in the development of PSR-7. -- You received this message because you are subscribed to

Re: [CC][Nomination] Matthew Weier O'Phinney

Nomination registered, thank you both! Il giorno martedì 30 aprile 2019 17:53:05 UTC+2, Matthew Weier O'Phinney ha scritto: > > Thank you for the nomination, Chris! > > Accepted! > > On Tue, Apr 30, 2019 at 10:16 AM Chris Tankersley > wrote: > >> I would like to nominate Matthew Weier

[CC][NOMINATION] Matteo Beccati

I would like to nominate Matteo Beccati (@mbeccati) for the upcoming CC elections. Matteo is a longstanding project representative in PHP-FIG for Revive Adserver, and he is constantly giving to the community through Grusp, the italian association that is behind all the italian PHP user groups

[Secretary][NOMINATION] Asmir Mustafic

I would like to nominate Asmir Mustafic (@goetas_asmir) for the upcoming secretary election. Asmir is a consultant with a particular focus on PHP, Symfony, API & devops. He recently took on the maintainer role for the JMS Serializer package doing a great work, with a complete overhaul and a

[VOTE] Core Committee Election

ng phase I will be announcing the results, and all the newly elected (both CC members and secretary), as announced before. Vote ordering will be also used to assign the terms, so the last of the elected will take the shorter one. Thanks! Alessandro Lai PHP-FIG Secretary [1]: STV User-friendly E

[CC][Nomination] Benni Mack

I would like to nominate Benni Mack (https://github.com/bmack). He is the project lead for TYPO3, and he has recently participated in the PHP-FIG in the approval of PSR-14, by being a member of the working group. -- You received this message because you are subscribed to the Google Groups "PHP

Re: [BYLAW] Proposal: let PSRs evolve with the language

A Twitter thread started from Nicolas Grekas is gaining traction about this specific discussion: https://twitter.com/nicolasgrekas/status/1174290079105392645 Can we push this forward somehow? Il giorno venerdì 7 giugno 2019 10:46:18 UTC+2, Alessandro Lai ha scritto: > > I'm very inte

Re: [BYLAW] Proposal: let PSRs evolve with the language

Since there seems to be a lot of confusion about what changes could be made code-wise and what not, I prepared a summary table for all the combinations of possible versions, using PSR-3 and Monolog v1-v2 as test subjects:

Re: [BYLAW] Proposal: let PSRs evolve with the language

I took more time on this issue and I've added a second sheet to the previous document: https://docs.google.com/spreadsheets/d/1QY7AUVQbWnVCbOZqJX11tbz2gKr-pU0CeZezcyJsEPA The second page stems from my proposal, and it shows the scenario for a package that extends Monolog, so it has to be

Re: Revert inappropriate PSR-12 post-vote merge

Since the PRs are opened by the editor and are approved by all 3 secretaries, I'll proceed to merge them. Korvin, it's up to you to reopen the discussion that will lead to the errata vote then. Sorry for the mixup. Il giorno mercoledì 18 settembre 2019 19:21:40 UTC+2, Korvin Szanto ha

[VOTE][PROJECTS][BYLAW] PSR evolution

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 document that addresses the issue of upgrading the code of a PSR to leverage new language features. I started

[VOTE][CC][BYLAW] PSR evolution

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 document that addresses the issue of upgrading the code of a PSR to leverage new language features. I started

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

Jordi, Nikolaos, you are project representatives, not CC members, this is the wrong thread. Il giorno martedì 12 novembre 2019 15:15:47 UTC+1, Nikolaos Dimopoulos ha scritto: > > +1 > > Thank you > > On Monday, November 11, 2019 at 4:48:24 AM UTC-5, Alessandro Lai wrote: &g

Re: PSR-17: HttpFactoryInterface maybe?

It also more importantly violates another SOLID principle, the I (interface segregation): having separate interfaces doesn't stop the implementers from having a single service that implements them all. So forcing that merge through a PSR interface is uncalled an not needed at all. Il giorno

Re: PSR-7: reuseful Request, how change body content?

Anton please keep it to a civil tone. Talking about "mistification" is not friendly nor acceptable here. As already said by MWOP, supporting PSR-7 alone has absolutely sense, and there are tons of packages that do that, because they care only about working on requests, not creating them. Il

Re: [BYLAW] Proposal: let PSRs evolve with the language

Hello George, I agree with you with the first part: the first step in our proposal could be easily wrapped in a minor release, it shouldn't hinder the adoption, and it would even encourage it, since it would be automatically adopted by any package that declares ^1.0 as a constraint. But making

Re: [BYLAW] Proposal: let PSRs evolve with the language

he interface with > parameter TypeB. > After tagging a new minor version with parameter TypeA, client code will > break. > > To be perfectly safe, we need to mark it as a major version and all > libraries are required to make a small change. > > Regards, > Alex > >

Re: [BYLAW] Proposal: let PSRs evolve with the language

Adrien the issue lies in the fact that in that way you would be forced to update ALL the dependencies that rely on that interface. In the case of very common PSRs, like psr/log, that would mean being blocked a lot, and having to be forced to do a big-bang update with a single deploy, and no

  1   2   >