Re: [Internal] [Discussion] Paul M Jones

[Alessandro Lai]

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 expulsion, if not, just for 
the sake of the fact that PMJ should be able to post here afterwards anyway, 
like anyone else, so that wouldn't resolve the main issue, that is profess and 
effective communication. 

I do agree to the fact that some degree of confrontation is needed when a 
technical (and often difficult) decision needs to be made, but an async and 
written medium like this one warrants a special and additional level of care 
and empathy, due to the limited ways of expressions that we have at hand. On my 
opinion, PMJ has demonstrated not enough empathy and professional respect in 
this mailing list and the FIG repository on Github, as many others have pointed 
out in this thread already; and I say this even if often I agreed with his 
point of view; in fact, I was just made uncomfortable just by his way of 
express his ideas, without taking into account in any way how the other part 
would have received that. 

In the end, I think that a change of pace from him would be the best solution 
for everyone, so we wouldn't have to loose someone with such competence, 
without having all this issues with him, that are like an handbrake on al the 
FIG's efforts on putting out new PSRs. 

Thanks for your patience. 

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/de7cd5e4-b140-4e76-a889-3eefe2c3aa2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internal] [Discussion] Paul M Jones

[Alessandro Lai]

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, so you 
basically CAN'T ignore him, because is part of the process.
We are not here to casual discuss something, if I ignore someone it's 
detrimental to the PSR process. Right now, if I'm not mistaken, he is the 
sponsor of 2 drafting PSR: if I would like to work on those, I have to work 
with him, it's unavoidable.

That's why we're asking to him to police his tones. Even in this thread, he 
wrote some personal comments that he could have avoided; I understand his 
frustration about this mess, but he displayed the same carelessness and 
abrasiveness that we're accusing him to perpetuate, that is the root cause 
of this thread itself. I agree with you that the "advice process" is a bit 
strange and drifts into something somewhat improper, but we didn't reach 
any other solution, short of removing him (that I found useless and 
detrimental to both parts).

Il giorno martedì 12 luglio 2016 05:54:54 UTC+2, Tom Etzel ha scritto:
>
> I've been holding my opinion on this whole thing thought I would just keep 
> my mouth shut. However, I have now read through every single thread, and 
> read through every single example of "wrong doing", or "dickishness", or 
> whatever you want to call it and I still felt I could just keep my mouth 
> shut and see how this played out. That was until this comment:
>
> "Based on this assumption I would propose that Paul, at least for a 
> certain amount if time submit his postings to a form of “advice process”:
> http://guides.shiftbase.net/advice-process-2/ (note I didn’t really find 
> a nice and compact explanation and this is the best I found).
>
> The fundamental idea is that Paul would submit his postings to a subgroup 
> to get advice on the wording. He is however not obligated to integrate said 
> advice."
>
> That has to be a joke right? You cannot be seriously suggesting 
> institution of a language police sub-forum. I mean... I am seriously hoping 
> that this was sarcasm that didn't translate through the internet correctly.
>
> A lot of the posts to this thread have been about how 1 person's supposed 
> actions can supposedly drive people away from this group, or keep people 
> from wanting to participate for fear of being Judged, ridiculed, spoken 
> meanly too, or having their feelings hurt by Paul. I have a counter point 
> for you. Anyone who truly knows me knows that I typically do not fear 
> saying things bluntly, that may offend people. As a combat veteran I long 
> ago realized that life is too short to tiptoe around every little thing in 
> life. All that being said... the reason it took me so long to stand up and 
> write something on this thread was out of fear of being put down, or 
> silenced, or looked at as a lesser person... not by Paul, but by a couple 
> of you who seem to want nothing more than the man gone because you don't 
> agree with his politics or his direct communication style. It's ridiculous, 
> and it makes me sad for this group. If you don't like the guy or what he 
> has to say... ignore him. In this day and age you can't go anywhere on the 
> internet without someone possibly offending you. Are you all declaring war 
> on every person on every site on the internet that offends you in some way? 
> I highly doubt it. So why here, why now?
>
> Frankly, I wish the effort spent screwing around with this nonsense was 
> directed toward continued work on PSRs. Especially since most of you say 
> it's his voice on these forums that is the problem, and in the same breath 
> recognize that removing his vote doesn't remove his voice
>
> Sorry... I know I have rambled. I got fired up and that's what happens 
> sometimes. Hopefully some of this is clear enough to express my point.
>
> On Monday, July 11, 2016 at 1:20:37 AM UTC-5, Lukas Kahwe Smith wrote:
>>
>>
>> On 10 Jul 2016, at 16:13, Rafael Dohms  wrote:
>>
>> On Sunday, July 10, 2016 at 4:57:58 AM UTC+2, pmjones wrote:
>>>
>>>
>>> > On Jul 9, 2016, at 16:28, Anthony Ferrara  wrote: 
>>> > 
>>>
>> *I think the ball is in Paul's court, if I was in his shoes I would 
>> really do some soul searching, talk to the people on this list and try to 
>> figure out what is really wrong, those conversations alone could help a 
>> lot.*
>>
>> *Now if these 2 weeks do not end up with a viable solution, then the vote 
>> for removal would be another message.*
>>
>>
>> Honestly I find this a bit unrealistic. ie. even if Paul has done said 
>> soul searching, a 2 week timeline on some epiphany is a bit unrealistic to 
>> ask, let alone its not clear to me how he would be able to communicate said 
>> epiphany unless it would entail him basically recanting is entire past.
>>

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

[Alessandro Lai]

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 receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/c7596787-9110-4a79-9629-1b5afbee3660%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 situation: Paul just voted for itself as a secretary. 
This seems to me a big, unresolved, conflict of interests. 

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/dbfe2ddb-9183-4ac5-9848-f93867d1763a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 *-interop groups can still be formed and promoted, even outside of the 
FIG reach; then, each *-interop can choose to "be embraced" by the FIG, 
where the work (which is already done) can be formalized as a PSR, with 
little work and two simple votings.

What do you think?

Il giorno lunedì 8 agosto 2016 15:57:39 UTC+2, pmjones ha scritto:
>
> Dear Voting Members, 
>
> There is another way to solve the problems listed in the [FIG 3.0 
> summary][1]: formally encourage the creation of a *-interop project as a 
> prerequisite to a FIG entrance vote. (Look to container-interop and 
> async-interop as examples.) 
>
> * * * 
>
> Point by point from the FIG 3.0 tl;dr: 
>
> > Everyone has equal say on FIG PSRs, no matter their expertise or their 
> project’s relevance in the PSR’s problem space 
>
> A *-interop project concentrates on its particular problem, and can invite 
> (or draw the attention of) those who have relevant expertise.  Both 
> container-interop and async-interop were able to this successfully. 
>
> > There are lots of clever awesome people involved in the FIG who are not 
> project representatives 
>
> A *-interop project need not be limited to only project representatives. 
> It can accept (or refuse) anyone it wants. 
>
> > Member projects find it difficult to engage in everything going on in 
> the FIG 
>
> Interested parties can enagage in as many, or as few, *-interop projects 
> as they like. 
>
> > There is an ongoing question if the FIG produces PSRs for member 
> projects or for the wider community; especially when the wider community 
> pays it so much attention due to its de-facto status as ‘the php standards 
> body’. 
>
> Each *-interop project can define for itself the audience it addresses. 
>
> * * * 
>
> This has several advantages over the FIG 3.0 approach. 
>
> - fewer rules changes (perhaps only one!) 
>
> - less bureaucracy 
>
> - less centralization 
>
> - reduced hierarchy 
>
> - fewer committees 
>
> - more flexibility 
>
> - greater openness 
>
> Each *-interop gets to operate in the way it likes, according to its own 
> project members. 
>
> Each *-interop can work through its ideas among a smaller set of 
> interested participants, perhaps with implementation trials, without having 
> the pressure of "being a standard" from the outset. 
>
> Once a *-interop project feels it has solved its particular problem, it 
> can petition for FIG entrance under current FIG bylaws. 
>
> If there is more than one *-interop groups tackling the same problem in 
> different ways, FIG can pick from the different groups, or ask that they 
> merge their efforts before entrance. 
>
> FIG can also see how broadly the work of *-interop group has been 
> accepted, providing real-world information as to the value of the work 
> before the entrance vote. 
>
> * * * 
>
> Please consider this the opening of the 2-week discussion that occurs 
> prior to a vote; of course, it may go on longer than that. 
>
>
> [1]: https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b#.4fhp3srq0 
>
> -- 
>
> Paul M. Jones 
> http://paul-m-jones.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b14f9c91-265b-4606-80c0-fdbfcbf37169%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Alessandro Lai]

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 
>> missing". We don't need this because users of containers can anyway figure 
>> that out.
>>
>
> I'd like to propose the opposite alternative. That's no a rebuttal of 
> yours and I sincerely thank you for being so open to comments.
> Let's see:
> My naïve question was "doesn't that concept [NotFoundExceptionInterface] 
> duplicate the "has()" method?"
>
> Your new proposal is to answer a strict "no" to this question, thus remove 
> the exception all together.
> What about answering it with a strict "yes"?
>
> What I mean is to keep NotFoundExceptionInterface and define it a to be 
> thrown by "get" only and only if would have returned false.
> I think that would fix Larry's comments, and more importantly, fix any 
> ambiguity and the semantic of this exception.
>
> So, to sum up, error handling in PSR11 could look like:
>
> - "has" never throws anything but instanceof \Error - it only returns 
> true/false
> - "get" throws NotFoundExceptionInterface whenever "has" would have 
> returned false - it "directly" throws ContainerExceptionInterface - and 
> is allowed to let anything else bubble if thrown by the 
> factories/initializers it calls.
>
>  
>
>> It also enforces best practices as users that want to check if an entry 
>> exists will use has instead of NotFoundExceptionInterface (the exception 
>> can no more be used for control flow)
>>
>
> This is the main difference with your proposal: NotFoundExceptionInterface 
> could be used for flow control. But since doing so would be strictly 
> equivalent to call "has", we could even add in the PSR a SHOULD NOT - if 
> worth it.
>
> Does it make sense?
>
> Nicolas
>
>
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/e37fddb3-dcfa-4b0c-b2c8-83f9ffb3e399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

[Alessandro Lai]

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 agosto 2016 01:03:01 UTC+2, Alexander Makarov ha 
scritto:
>
> Chris Tankersley, thanks for info. I've somehow missed renewal terms. 
> Members are elected for 2 years. That's probably a bit lengthy period.
>
> Do you know why the number of core committee members is exactly 12?
>
> I understood that after work is done, proposal is passed to core committee 
> for final vote. I still wonder what happens if current core committee 
> members do not have expertise about the topic to vote... they can ensure 
> quality of the text itself and its clarity but can't ensure that the 
> proposal itself is a good one. Probably not a big issue since proposal 
> already 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' via PHP Framework 
>> Interoperability Group  wrote:
>>
>>> 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 
>>>
>>
>> If I remember correctly, the idea was to have a smaller, dedicated core 
>> group to encourage the members to be more active. All of the work regarding 
>> each PSR will be handled by the individual working groups though, which may 
>> contain core members but ideally are made up of many different member 
>> projects. 
>>  
>>
>>> 2. Why 12 exactly? What if there's a PSR on a topic any of these 12 
>>> members don't care about or don't have expertise about?
>>>
>>
>> That's what the working groups are for. The Working Group should be made 
>> up of people interested and knowledgeable about the topic. When the PSR is 
>> all finished (wording and two implementations) and ready to be finalized, 
>> it's passed onto the core committee for a final vote. 
>>  
>>
>>> 3. Have I missed information about how core committee members are 
>>> rotated / re-elected?
>>>
>>
>> That info was in the PR for the change. I'm on mobile otherwise I would 
>> link to 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to php-fig@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/php-fig/8629479a-0c05-468d-9705-a1003d1bc368%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Chris Tankersley
>> http://ctankersley.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/5f9f8966-8956-4ef4-9b65-7dfad796254a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

[Alessandro Lai]

Understood, thanks for the clarification. Seeing the "old" bylaw, I suspect 
the same.

Il giorno giovedì 25 agosto 2016 02:13:38 UTC+2, Michael Cullum ha scritto:
>
> Hi Alessandro,
>
> Larry asked me to just jump in and clarify this (the legalese part of the 
> spec was mostly from me and this also relates to existing bylaws).
>
> It's based on the current wording (and rounding rules) in the current 
> Voting Protocol where no tie is possible, the burden of proof, so to speak, 
> lies with the person calling for a motion to pass and rounding is clarified 
> through examples. This appears to be the easiest way to do it to be honest 
> without lots of verbosity which has the ability to hinder understanding 
> than improve it. If you have any alternative suggestions for wording they 
> would be most welcome although I suspect a similar discussion occurred when 
> the original Voting Protocol was written (PMJ: Perhaps you could confirm 
> this?).
>
> I would draw note to the current voting protocol, in particular points 5 
> and 6: 
> https://github.com/php-fig/fig-standards/blob/master/bylaws/001-voting-protocol.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 is somewhat 
>> "implicit" in there.
>>
>> Il giorno mercoledì 24 agosto 2016 15:51:27 UTC+2, Larry Garfield ha 
>> scritto:
>>>
>>> Can you note anything in particular that is clumsy to read?  We were 
>>> aiming for explicitness and lack of vagueness, 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 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, August 24, 2016 at 1:07:40 AM UTC+3, Alessandro Lai wrote: 
>>>>
>>>> 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 is possible. 
>>>>
>>>> Are there any other doubts to be settled?
>>>>
>>>
>>> -- 
>> 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/1878ff62-fb7a-458d-b83a-5cfdb9a7733b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/1878ff62-fb7a-458d-b83a-5cfdb9a7733b%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/65c5b108-1d43-47a2-88ab-bba5161c66b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resigning My Position ...

[Alessandro Lai]

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 as sponsor of PSR-8, the "Huggable" Interface. 
>> This was a fun joke way-back-when, but its time has passed. 
>>
>> And if I may suggest it, perhaps the editor should voluntarily withdraw 
>> the PSR from consideration. 
>>
>> Thanks everyone! 
>>
>  
> Is this "voluntary withdrawal" even a thing? If the authors and sponsors 
> want to walk away, then surely they can. The PSR is then out of their 
> hands. Other people can take it on, or it is abandoned. The idea that 
> someone can say that they no longer want to be involved in developing a 
> PSR, and no-one else can either, seems a little dangerous to me.
>
> -- 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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d2abd198-de7f-4be4-b648-4e2e6ab5ef6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PRE-VOTE DISCUSSION] Withdraw PSR-8

[Alessandro Lai]

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 Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/0ea1454d-ae0f-4aeb-9e22-559abf0d8099%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b55ff8ae-9cbf-48f3-8474-ad6ac19a4d8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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. 
> https://github.com/php-fig/fig-standards/pull/752/files#diff-b58538881047f8ede6b65a2ca2e01261R62
>
> > Acting throughout their term essentially as Developer Advocates for the 
> PHP FIG
>
> I have never heard the term "Developer Advocate"...
>
> Why exactly do we need "Advocates" as secretaries. That does not make any 
> sense at all. Having a core-committee member being an advocate ... okay, 
> but not a secretary.
>
> Defintion of "Advocate" (for those whom might not have english as their 
>> first language) : a person who publicly supports or recommends a 
>> particular cause or policy.
>
>
>
> As it currently reads, a secretary can publicly support say a different 
> implementation of a problem. 
>
> Is this a problem?
>
> I think so.  A secretary's role is NOT to be recommending solutions but to 
> facilitate finding a solutions.
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/01f5dba2-2c50-4e26-835e-fe6ab957b521%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

[Alessandro Lai]

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 is possible. 

Are there any other doubts to be settled? 

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/17303cd3-3953-4ecc-957b-231ad3fd1ef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

[Alessandro Lai]

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 and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/f386c41a-5b86-4da8-a575-9099c57346de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

[Alessandro Lai]

Larry, it think that the part about vote rounding is not clear enough; it's 
understandable through the examples, but the rule is somewhat "implicit" in 
there.

Il giorno mercoledì 24 agosto 2016 15:51:27 UTC+2, Larry Garfield ha 
scritto:
>
> Can you note anything in particular that is clumsy to read?  We were 
> aiming for explicitness and lack of vagueness, 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 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, August 24, 2016 at 1:07:40 AM UTC+3, Alessandro Lai wrote: 
>>
>> 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 is possible. 
>>
>> Are there any other doubts to be settled?
>>
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/1878ff62-fb7a-458d-b83a-5cfdb9a7733b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 push it to approval.

Il giorno giovedì 17 novembre 2016 12:52:29 UTC+1, Alessandro Pellizzari ha 
scritto:
>
> On 17/11/2016 11:29, David Négrier wrote: 
>
> > I know some of you have doubts about this part of the PSR, so the first 
> > thing might be to decide whether we want to keep it or not. If we decide 
> > to keep it, I'm sure there are plenty of things we can do to improve the 
> > wording :) 
>
> I see the advantages of using delegate containers (I use them daily), 
> but honestly I don't think they should go in this PSR. 
>
> PSR-11 is focused on getting things from a container, and delegates are 
> completely transparent from this POV. 
>
> As long as a Container implements get() it can become a delegate of a 
> (possibly) more powerful Container that implements delegation. 
>
> I think it would be better in a "Container creation and configuration" 
> PSR. 
>
> Bye. 
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/59576a50-0bbe-4901-ae45-c0a4d98a9484%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 just 
> an example. I am just wondering when things going towards standards then 
> why is NULL not considered to be a standard value. NULL is wanted sometimes 
> to express that someting is optional. 
>
>
> Am Donnerstag, 3. November 2016 14:31:52 UTC+1 schrieb Sven Sauleau:
>>
>> Hi,
>>
>> The goal of the php-fig/log repository is to provide interfaces and more 
>> globally a standard for logging. You are pointing out an implementation 
>> issue.
>>
>> The code you saw in the README is only an example.
>>
>> A real example would be like 
>> https://github.com/Seldaek/monolog/blob/7ce63f964426a57b6a1c213d45e05eef1f013c54/src/Monolog/ErrorHandler.php#L42
>>  
>> (also from Seldaek).
>>
>> Le vendredi 4 novembre 2016 06:16:34 UTC+6, n.y...@gmx.at a écrit :
>>>
>>> Can you guys please answer this question to me
>>>
>>> http://stackoverflow.com/questions/40401259/psr-log-why-no-null-default-value-for-loggerawareinterface-and-loggerawaretraiace
>>>  
>>> and LoggerAwareTrait
>>>
>>> Thank you
>>>
>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/177245f5-0b5f-42d4-b37d-ab447bf00c5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Alessandro Lai]

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, like PSR-0 has been for PSR-4. 
Please, don't let the limited scope of this PSR be a disadvantage, because 
IMHO it's the opposite. 

Il giorno venerdì 13 gennaio 2017 20:07:34 UTC+1, Nicolas Grekas ha scritto:
>
> Thanks for your answer Máté
>
>
> Without ContainerInterface, I should have used an Adapter (e.g. the 
>> Acclimate package) or I could have hardwired a specific container into my 
>> framework to achieve so (I would have hated both solutions).
>>
>
> It looks like the only feature of PSR11 that this is using is the "get" 
> method.
> No "has", and no exception-related logic.
> That basically means a simple closure would do the job equally well, isn't?
>
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/7d588b40-6364-4985-9600-7262e2645268%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 leverage 
PSR-11 itself, as a published and approved PSR.

Il giorno martedì 20 dicembre 2016 11:18:24 UTC+1, David Négrier ha scritto:
>
> As I already explained, I'm a bit reluctant to remove the delegate lookup 
> feature because I really wanted to raise awareness of this design pattern 
> (otherwise, composing containers is almost useless). That being said, I 
> guess I need to listen to feedback, and the feedback we received in this 
> thread is mostly that it's not essential to PSR-11.
>
> I wanted to work on a v2 of the delegate lookup feature with a better 
> wording, but I probably won't have time before we switch to FIG 3.0. And 
> I'd definitely prefer PSR-11 to pass the vote with FIG 2.0 (it seems 
> pointless to create a whole working group on PSR-11 as it is already 
> finished :) )
>
> So here is the PR that removes the delegate lookup feature from PSR-11: 
> https://github.com/php-fig/fig-standards/pull/854
>
> Reviews are welcome. That way, we can gauge if the feature is needed after 
> PSR-11 adoption and come back to it in another PSR if needed.
>
> ++
> David
>
>
>
> Le samedi 26 novembre 2016 17:56:40 UTC+1, Chuck Burgess a écrit :
>>
>> I would leave it out of this spec, and perhaps apply the invested effort 
>> into a DDL spec and/or reference implementation atop this spec.  The need 
>> for this spec to go out into the world seems greater to me than the 
>> realized benefits of forcing implementations of this spec to include the 
>> DDL feature.
>>
>> CRB
>> *about.me/ashnazg *
>>
>> On Thu, Nov 17, 2016 at 5:29 AM, David Négrier  
>> wrote:
>>
>>> Ok folks!
>>>
>>> I've been delaying this for a while to give some room for the rest of 
>>> the questions about PSR-11, but now is the time to dwelve into the details 
>>> of the delegate lookup feature :)
>>>
>>> I know some of you have doubts about this part of the PSR, so the first 
>>> thing might be to decide whether we want to keep it or not. If we decide to 
>>> keep it, I'm sure there are plenty of things we can do to improve the 
>>> wording :)
>>>
>>> (post is quite long and contains images. If it does not display well, I 
>>> cross-posted 
>>> here 
>>> 
>>> )
>>>
>>> *What is it?*
>>>
>>> The *delegate dependency lookup feature* (let's call it DDL) is a *design 
>>> pattern.*
>>> It is the only way we have found to compose containers.
>>>
>>> *What problem does it solve?*
>>>
>>> Let's admit you want to compose/chain containers (more on why you might 
>>> want to do this later).
>>> To do this, you would typically use a "CompositeContainer 
>>> "
>>>  
>>> (a container without any entry whose role is to ask each "child" container 
>>> in turn "do you contain the entry I'm looking for?")
>>>
>>> [image: composite.png]
>>>
>>> The CompositeContainer is not enough. Let's admit container 1 contains 
>>> your controller. You fetch your controller. Your controller has a 
>>> dependency on your ORM's entity manager. If the entity manager is part of 
>>> container 2, container 1 will be unable to fetch it (because internally, it 
>>> will perform a call "$this->get()" to fetch the entityManager dependency. 
>>> Similarly, the entityManager should be able to fetch a dependency (for 
>>> instance the dbConnection) inside another container...
>>>
>>> The delegate lookup feature simply states that containers should not 
>>> fetch their dependencies locally, but instead, they should fetch their 
>>> dependencies from the top-most container (in this example, this is the 
>>> CompositeContainer).
>>>
>>> In our example, this would go like this:
>>>
>>> - The framework asks for the "controller" entry to the CompositeContainer
>>>  
>>> - The CompositeContainer asks Container 1: "do you have "Controller". 
>>> Container 1 answers yes
>>> - The CompositeContainer asks Container 1: "give me "Controller".
>>> - Container 1 needs to fetch the "EntityManager" dependency, so 
>>> Container 1 calls *$compositeContainer->get('EntityManager')*; (here! 
>>> container 1 is "delegating" the dependency lookup to the composite 
>>> container)
>>> - The CompositeContainer asks Container 1: "do you have "EntityManager"? 
>>> => response is no.
>>> - The CompositeContainer asks Container 2: "do you have "EntityManager"? 
>>> => response is yes. The CompositeContainer asks Container 2: "give me 
>>> "EntityManager".
>>> - ... and do on
>>>
>>>
>>> *Do we want this?*
>>>
>>> To be honest, PSR-11 is already useful without the DDL feature. The 
>>> 

Re: First Core Committee Members!

[Alessandro Lai]

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 2019):*
>
>- Matthew Weier O'Phinney
>- Sara Golemon
>- Larry Garfield
>- Beau Simensen
>
> *Second Four Candidates (Until August 2018):*
>
>- Lukas Kahwe Smith
>- Samantha Quiñones
>- Cees-Jan Kiewiet
>- Gary Hockin
>
> *Third Four Candidates (Until January 2018):*
>
>- Chris Tankersley
>- Graham Daniels
>- Korvin Szanto
>- Stefano Torresi
>
> --
> Michael Cullum
> 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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/00ee099b-d14f-4c5c-9a2a-ec6bef43d14b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Alessandro Lai]

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:
>
> Excellent questions. Thank you.  
>
> The buy-in would be the same for every PSR, wouldn't it? Libraries do not 
> want to depend on an implementation or provide an implementation 
> themselves. They want the user to decide if a highly flexible client 
> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
> https://github.com/joelwurtz/http-client-benchmark). Also, as you 
> probably noticed, there are representatives from all PSR7 compliant HTTP 
> clients in the workgroup. 
>
>
> That last point was what I was getting at, thank you.  By buy-in, I mean 
> "do we have an indication that the major HTTP clients are going to adopt 
> it?"  It sounds like the answer is a loud "yes", which is great to see.
>
> The simplest answer of async or not is: There is not PSR for Promises yet. 
> I do not think the PSR for HTTP clients should define what the industry 
> standard for a Promise should be. I do also not think we should wait with a 
> PSR for HTTP clients until (if ever) a PSR for promises has been released. 
>
> We, php-http team, have followed discussions in 
> https://github.com/async-interop that sadly has been put on hold. 
>
>
> A fair reason, thanks.  It may be worth mentioning in the metadoc, 
> including what a future Async version MIGHT look like if/when a Promises PS 
> happens.  (You don't need to implement it, just show that it could still be 
> implemented.)
>
> --Larry Garfield
>
> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote: 
>>
>> The key for me is if the various HTTP clients have buy-in to implement 
>> the spec once completed.  Is that the case?
>>
>> I would also ask why this is just for sync HTTP clients, not async.  
>> There's plenty of use cases for the latter.  That may be scope creep, but I 
>> feel it's worth asking.
>>
>> --Larry Garfield
>>
>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>
>> Hi, 
>>
>> +1 for first creating working stuff and later doing effort to make it a 
>> good standard. Way better approach than the other way round :)
>>
>> Great work.
>>
>> Cheers and great weekends!
>> --
>> Tuomas
>>
>>
>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  
>> wrote:
>>
>>> Hey, 
>>>
>>> This looks interesting, would have to study this in detail but I do like 
>>> the simplicity from a quick read through.
>>>
>>> Cees-Jan 
>>>
>>>
>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm  
>>> wrote:
>>>
 Hey.  

 Im a co-creator of HTTPlug and a maintainer of a number of API clients. 
 I would really like to see a PSR for synchronous HTTP clients. The HTTPlug 
 has created a "meta-standard" which has been stable for 18 months now. We 
 believe it is a really good interface and would like it (or something 
 similar) to be an official PSR. 

 I would ask the Fig for an entrance vote.

 *Here is a first idea: *
 PSR: 
 https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
 Meta: 
 https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md

 *Workgroup*:
 These people has been contacted and said they are interested in 
 participating in a workgroup. 

- Tobias Nyholm
- Sara Golemon (cc)
- Matthew O'Phinney (cc) (Maybe)
- Mark Sagi-Kazar 
- Jermey Lindstrom
- David Buchmann
- Joel Wurtz
- Simon Asika
- Christian Lück
- David De Boer


 -- 
 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/0db70a2c-d528-44df-b7f5-62387eb67872%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 
>>> 

Re: UX/UI designer || Denver , CO

[Alessandro Lai]

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 29 Jun 2017 15:07, "neha gupta"  
> wrote:
>
>> Hi,   
>>
>> Here is our Implementing partner Requirement. 
>>
>> Once you feel free please call me or Email me @ neh...@nityo.com 
>> 
>>
>>  
>>
>> *Role : UX/UI designer*
>>
>> *Location : Denver , CO*
>>
>> *Duration of contract: 12 months *
>>
>> *Interview: Phone/ Skype * 
>>
>> *Client : TCS(WWW.TCS.COM )*
>>
>>   
>>
>> *Mandatory Technical Skills*: 
>>
>> Expertise required in - Adobe Photoshop, Screen mock design, UX/UI 
>> design, Responsive website design, Wireframe experienceNice to have - HTML 
>> and CSS
>>
>> Key Responsibilities
>> Eight or more years of UX design experience.
>> Facilitate client’s product visions by researching, conceiving, 
>> wireframing, sketching, prototyping, and mocking up user experiences for 
>> digital products.
>> dentify design problems and devise elegant solutions
>> Make strategic design and user-experience decisions related to core, and 
>> new, functions and features.
>> Take a user-centered design approach and rapidly test and iterate your 
>> designs.
>> Collaborate with other team members and stakeholders.
>> Ability to iterate your designs and solutions efficiently and 
>> intelligently.
>> Ability to clearly and effectively communicate design processes, ideas, 
>> and solutions to teams and clients.
>> A clear understanding of the importance of user-centered design.
>>
>>  
>>
>>  
>>
>>  
>>
>> *Thanks & Regards,*
>>
>> *Neha Gupta*
>>
>>
>> *Desk no : 609-853-0818 Ext-2105 Fax :   609 799 5746 *
>>
>> *neh...@nityo.com  *
>>
>>
>> *neha.gupta1...@gmail.com  (www.nityo.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/CAB6E081Wniy-JntmpaLmQ1XZO-3iSVv_wvtkkK6_9hzr8nS7ZA%40mail.gmail.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8462e32b-445b-44ca-a0f3-34fe0fe395d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 this 
important, and I think also that the flow of execution between methods has 
some importance in the order between them; I think that also "Clean Code" 
suggests something like "keeping near a called method".

Il giorno domenica 4 giugno 2017 15:19:38 UTC+2, Кирилл Фрейман ha scritto:
>
> Hi everyone!
>
> In PHP de-facto exists some best practice of ordering methods and 
> properties. 
> It seems to me that this order is most common:
>
> Constants
> public const
> protected const
> private const
> Properties
> public static properties
> public properties
> protected static properties
> protected properties
> private static properties
> private properties
> Methods
> magic methods
> public static methods
> public methods
> protected static methods
> protected methods
> private static methods
> private methods
>
> Should we standartize 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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/30e2630a-801a-4399-a3d0-598174427b67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Survey: Naming things

[Alessandro Lai]

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ì 8 maggio 2017 03:01:32 UTC+2, Larry Garfield ha scritto:
>
> On 04/11/2017 03:19 PM, Larry Garfield wrote: 
> > Hello, peoples.  In response to some recent off-list discussion (at 
> > conferences and elsewhere), I offer this brief survey about how we 
> > should namespace interface PSRs once we start producing "updated" 
> > versions (eg, PHP 7-ified versions) of existing specs.  The survey 
> > itself has more details, and should take under a minute to complete.   
> > Please do so! 
> > 
> > 
> https://docs.google.com/forms/d/e/1FAIpQLSc8VJySoz_3koQThe057zYhzSkmOvOAgO0pEmenwr1Biu6JEA/viewform
>  
> > 
> > 
> > This is a non-binding information gathering tool only to kick off a 
> > discussion, not to end one.  Feel free to discuss more in this 
> > thread.  I'll leave the survey open for 2 weeks or until people stop 
> > responding to it. :-) 
> > 
> > All are welcome and encouraged to respond, even if you're not a Core 
> > Committee member or Project Rep. 
> > 
> > --Larry Garfield 
>
> A bit late (I've been a bit distracted, plus DrupalCon), but I've closed 
> the poll.  The results are available here: 
>
>
> https://docs.google.com/forms/d/1XAi_RZW_Ang_N-QZEc0SU2DwmV-6n31elex2753d9QU/edit#responses
>  
>
> Items of note: 
>
> * Only 5/12 members of the Core Committee participated. :-( 
>
> * Only 7 project reps participated. :-( 
>
> * Overall, there seemed to be a strong lean toward "no change", vis, a 
> hypothetical updated PSR-20 logger would live in the \Psr\Log namespace 
> and the psr/log Composer package, with a 2.0 tag. 
>
> * That was far from a unanimous position, however.  All other options 
> had their adherents, although \Psr\Log\V2 seemed to be generally disliked. 
>
> The strong lean toward "stet", plus the discussion thread, makes me 
> think I did a poor job of explaining the problems with it.  So, let me 
> try again: 
>
> Consider PSR-3: 
>
> interface LoggerInterface 
> { 
>  public function emergency($message, array $context = array()); 
>  public function alert($message, array $context = array()); 
>  public function critical($message, array $context = array()); 
>  public function error($message, array $context = array()); 
>  public function warning($message, array $context = array()); 
>  public function notice($message, array $context = array()); 
>  public function info($message, array $context = array()); 
>  public function debug($message, array $context = array()); 
>  public function log($level, $message, array $context = array()); 
> } 
>
> Now consider a hypothetical "PHP7-ify only" PSR-20: 
>
> interface LoggerInterface 
> { 
>  public function emergency(string $message, array $context = 
> array()) : void; 
>  public function alert(string $message, array $context = array()) : 
> void; 
>  public function critical(string $message, array $context = array()) 
> : void; 
>  public function error(string $message, array $context = array()) : 
> void; 
>  public function warning(string $message, array $context = array()) 
> : void; 
>  public function notice(string $message, array $context = array()) : 
> void; 
>  public function info(string $message, array $context = array()) : 
> void; 
>  public function debug(string $message, array $context = array()) : 
> void; 
>  public function log(string $level, string $message, array $context 
> = array()) : void; 
> } 
>
> Off hand it seems like they should be easily compatible.  However, 
> consider that most packages are likely to be referencing it like so in 
> composer.json: 
>
> { 
>"require": { 
>  "psr/log": "~1.0" 
>} 
> } 
>
> That is, they are saying they're not compatible with psr/log 2.0. 
>
> Now we release PSR-20 as psr/log 2.0 on Packagist.  My Hare library 
> already requires PHP 7.3 (because I'm just that forward-looking) so I 
> can require it easily: 
>
> { 
>"name": "crell/hare", 
>"require": { 
>  "psr/log": "~2.0" 
>} 
> } 
>
> Michael's Tortoise library, however, is more staid (by which I mean, 
> only minimally maintained), and so he hasn't updated his composer.json 
> file.  It still says ~1.0. 
>
> Now Sara comes along and tries to write an application that uses both 
> crell/hare and michaelc/tortoise, because both are solid libraries that 
> do useful things.  Composer will, of course, not let her install both 
> the 1.0 and 2.0 versions of the same package, so it will simply error 
> out.  crell/hare and micahelc/tortoise are now utterly incompatible with 
> each other, because they depend on different versions of an 
> otherwise-identical logging interface. Both would technically work fine 
> if run on a 

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

[Alessandro Lai]

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 errata should be put forward, since PSR-6 is 
already in the wild and will not disappear the moment that we publish this 
"update", but IMHO having a future strategy at this could be a good thing 
(and a good precedent to be followed next time that an issue like this 
arises).

Il giorno lunedì 8 maggio 2017 02:08:24 UTC+2, Larry Garfield ha scritto:
>
> OK, I'm behind in this, but putting this forward again. 
>
> Last fall we discussed an Errata for PSR-6 around the handling of the 
> expiresAt() method, which is documented to use PHP 5.5-and-up features 
> but doesn't enforce it at the type hint level.  The recommended solution 
> in the errata last time was rejected, and there was expressed desire to 
> use an exception instead.  I therefore offer the following PR, which is 
> essentially the same prose as before but with a different code 
> recommendation: 
>
> https://github.com/php-fig/fig-standards/pull/915 
>
> I'll leave this for 2 weeks before calling a vote on it. Secretaries, 
> please clarify if this would be just a CC vote or a dual-vote.  (Since 
> it's an Errata on a spec, and specs are CC vote only, I would think it's 
> CC only but will accept the Secretaries' decision.) 
>
> --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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/4e8c86b9-273a-439c-b698-9d320d1fb3ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Secretary nomitation] Alessandro Lai

[Alessandro Lai]

Hi everyone, and thanks Matteo for the nomination, I accept it.

I'm following the FIG for a while now, I've joined the last two meetings at 
PHPDay, and I would like to help in here with the secretary role.
I already talked to Michael about the role, and if anyone wants to ask me 
any questions, 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 Milan PHP user group. He's 
> trying to help the PSR-12 WG and would like do lend a hand with the 
> secretary role. 
>
>
> Cheers 
> -- 
> Matteo Beccati 
>
> Development & Consulting - http://www.beccati.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/3d822752-47be-4e1e-8ebe-3872e953fa5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for extended coding style guide

[Alessandro Lai]

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 UTC+2, Anton Okolelov ha scritto:
>
> Hello
>
> Could you please add typecasting space issue in 
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
>  
> ?
>
> $intValue = (int)$stringValue;
>
> or 
>
> $intValue = (int) $stringValue;
>
> Thank you
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/4040126b-3eba-4146-b1d5-b12da2c0d851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for RDF interfaces

[Alessandro Lai]

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 2017 11:11:17 UTC+1, Pieter Colpaert ha 
scritto:
>
> As the author of hardf I +1 the need for such a specification and if this 
> would become a PHP-FIG standard, I will comply to it.
>
> Kind regards,
>
> Pieter
>
> Op dinsdag 7 november 2017 15:11:40 UTC+1 schreef Konrad A.:
>>
>> Hello,
>>
>> i would like to propose new interfaces representing RDF terms (
>> https://www.w3.org/RDF/) to have a basement for framework/library 
>> interoperability.
>>
>> # Motivation
>>
>> There are currently 5 RDF-libraries for PHP available (EasyRdf, Erfurt, 
>> hardf, ARC2 and Saft). Each implements different areas with various quality 
>> and feature-coverage. Combined, they provide a rich feature-set from RDF 
>> data handling, serialization and parsing to database access. 
>> Therefore it is important, that each library uses the same data model for 
>> RDF data to allow data interchange.
>>
>> # Background
>>
>> The proposed interfaces and example implementations are based on a PHP 
>> RDF framework i maintain (https://github.com/SaftIng/Saft). 
>> This means, that they are battle tested and i already created (basic) 
>> converter to work with all major frameworks.
>>
>> # Further information
>>
>> This is my first proposal and i am new to this PHP-FIG/PSR stuff, so if 
>> forgot something, please let me know. :)
>>
>> *Quick link for the specification:* 
>> https://github.com/SaftIng/fig-standards/blob/psr-rdf/proposed/rdf/rdf.md
>> *Link for interfaces and example implementation:* 
>> https://github.com/SaftIng/PsrRdf
>>
>> Kinda regards
>> Konrad Abicht
>>
>>
>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/4e1ac4f2-2d0e-4db7-aeca-71067b9a1bba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for RDF interfaces

[Alessandro Lai]

Michael (one of the current secretaries, besides me) already replied in the 
PR: https://github.com/php-fig/fig-standards/pull/958#issuecomment-345666199

Reach to him and ask any question you want.

Il giorno lunedì 20 novembre 2017 11:19:06 UTC+1, Konrad A. ha scritto:
>
> Hello Alessandro,
>
> 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 at 10:42:35 AM UTC+1, Alessandro Lai wrote:
>>
>> 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 2017 11:11:17 UTC+1, Pieter Colpaert ha 
>> scritto:
>>>
>>> As the author of hardf I +1 the need for such a specification and if 
>>> this would become a PHP-FIG standard, I will comply to it.
>>>
>>> Kind regards,
>>>
>>> Pieter
>>>
>>> Op dinsdag 7 november 2017 15:11:40 UTC+1 schreef Konrad A.:
>>>>
>>>> Hello,
>>>>
>>>> i would like to propose new interfaces representing RDF terms (
>>>> https://www.w3.org/RDF/) to have a basement for framework/library 
>>>> interoperability.
>>>>
>>>> # Motivation
>>>>
>>>> There are currently 5 RDF-libraries for PHP available (EasyRdf, Erfurt, 
>>>> hardf, ARC2 and Saft). Each implements different areas with various 
>>>> quality 
>>>> and feature-coverage. Combined, they provide a rich feature-set from 
>>>> RDF data handling, serialization and parsing to database access. 
>>>> Therefore it is important, that each library uses the same data model 
>>>> for RDF data to allow data interchange.
>>>>
>>>> # Background
>>>>
>>>> The proposed interfaces and example implementations are based on a PHP 
>>>> RDF framework i maintain (https://github.com/SaftIng/Saft). 
>>>> This means, that they are battle tested and i already created (basic) 
>>>> converter to work with all major frameworks.
>>>>
>>>> # Further information
>>>>
>>>> This is my first proposal and i am new to this PHP-FIG/PSR stuff, so if 
>>>> forgot something, please let me know. :)
>>>>
>>>> *Quick link for the specification:* 
>>>> https://github.com/SaftIng/fig-standards/blob/psr-rdf/proposed/rdf/rdf.md
>>>> *Link for interfaces and example implementation:* 
>>>> https://github.com/SaftIng/PsrRdf
>>>>
>>>> Kinda regards
>>>> Konrad Abicht
>>>>
>>>>
>>>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/dc6dfa3a-3a5c-4f4d-9f70-bce05816473f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

New Secretaries

[Alessandro Lai]

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 unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/632bb167-4b1d-48e5-9194-986aa85170fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PHPDay 2018 meeting recap

[Alessandro Lai]

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 status of pending PSRs:
- I'm personally trying to help pushing PSR-5 back into the draft phase; 
the CC sponsor is Michael, which attended the meeting via Hangout, and 
acknowledge the latest PR about the meta doc, which should be enough for 
moving on to the entrance 
vote: https://github.com/php-fig/fig-standards/pull/1026
- PSR-9 & 10 are currently abandoned, and they need some experts in the 
security field to proceed; Michael is already asking to some people about 
it to reboot them.
- PSR-12 is in review phase, and it has been discussed by the WG (which I 
recently officially joined, after months of helping from the shadows) and 
evaluated the copious feedback that we received in the previous weeks; we 
may need some small adjustments that are not trivial enough to stay in the 
review phase, so we may go back to draft phase, but for a minimal amount of 
time; the WG already agrees on what should be done, so the only delay 
should be the new mandated 4-weeks period for the review phase.
- PSR-14 has entered the draft phase and it's proceeding well thanks to 
Crell shepherding the WG very well (see his recent post on ML about this).
- PSR-17 is being worked on by the WG, from which we had Stefano attending 
the meeting.
- PSR-18 needs a review by Sara, Tobias pinged me about it: he may have 
spotted a language issue/probable bug regarding the interface that the PSR 
should include, that should be the same as HTTPlug's, apart from the added 
return type.

An other discussed topic was the fact that we had multiple feedback from 
the outside about the fact that we do not have a standard format for the 
PSRs themselves. We agreed that such guidelines should only matter in 
regard of correct rendering on the official site so, since it's just 
aesthetic, it should fall under the secretaries' responsibilities; we will 
try to check if there are PSRs with inconsistent formatting and fix them 
ASAP; we may write down some small guide about that later, so newer WGs 
will not struggle about this topic.

Last but not least, stickers were shared!

https://twitter.com/phpfig/status/995312958921170944

I hope that this is enough! Please pitch in if I forgot something!

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/f63686a0-7c9c-4d7b-9a55-ac5115c7e524%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 Crivelli ha 
scritto:
>
> This is a good news. I hope that this new draft status will allow us to 
> focus on *simplicity and consistency* within the spec (as opposed to with 
> existing code base). Even if that means "breaking" code out there, or even 
> breaking with PSR-2. This would be for the best in the long term. Of course 
> the `declare()` whitespace comes to mind, but I am sure that there other 
> things.
>
> Is there any specific plan on what the next move will be ? and who should 
> be involved ? and how ?
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/942fcf92-439a-43a8-aa1b-92f3fdf9f298%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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ì 16 maggio 2018 09:26:17 UTC+2, Alice Wonder ha scritto:
>
> I do not use an IDE. I do not like them.
> Typically the only comments I put at the end of a bracket is for end of 
> class and end of function. End of class is not needed when the file only 
> contains a class, but it provides visual consistency.
>
> I'm not sure why some people care if there is a comment at end of a 
> closing bracket. Why does it matter to them?
>
> On Friday, December 29, 2017 at 1:28:56 AM UTC-8, Alexander Makarov wrote:
>>
>> 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 used the style described, because inevitably, 
>>> some hint that describes the block is more helpful than nothing at all. The 
>>> project i currently work with is a nightmare of inconsistent patterns, 
>>> procedural logic crammed into class methods, etc. Just getting things 
>>> documented to understand inner workings of individual *blocks* (let 
>>> alone whole functions) has been a long, slow process.
>>>
>>> That said, perhaps moving the "end-of" comment to the line *inside* or 
>>> *after* the terminating *}* can be helpful in most cases, but not 
>>> perfect.
>>>
>>> }
>>> // END foreach($rows)
>>> }
>>> // END while ($count)
>>> // END ridiculously large if ($foo)
>>> } elseif ($bar) {
>>> // ...
>>> }
>>> // END ridiculously large if/elseif chain
>>> // END of foo()
>>> }
>>> }
>>>
>>> There's no ideal solution, given other rules about splitting chained 
>>> controls like "*} else[if ()] {*" because there's no good placement of 
>>> such a comment, nor good way to format it if complying with all the rules.
>>>
>>> On Sunday, 3 December 2017 05:07:03 UTC-5, Andreas Möller wrote:


 I have a style that includes commenting on closing braces of long 
 blocks to help readability. For example,

 class MyClass 
 {
...
 } // MyClass


 How about not writing long blocks to help with readability?

 There are a range of possibilities to refactor your code to avoid the 
 need for comments altogether. See https://refactoring.com/catalog/. 


 Best regards,

 Andreas

>>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/bcb57874-9523-4daf-8f8b-a7ec796ee638%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New representative for Magento

[Alessandro Lai]

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 Magento will be Anton Kril (
> anton.k...@gmail.com), who is Magento's Director of Architecture. His 
> knowledge and experience make him a much better fit for the 
> responsibilities.
>
> Cheers,
> Ben Marks
> Evangelist @ Magento
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/50e43b1d-ec13-4ecc-880b-cd59432e71ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5] Working Group Formation

[Alessandro Lai]

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 willingness of having a PSR on that topic.

Il giorno martedì 15 maggio 2018 20:34:51 UTC+2, Chuck Burgess ha scritto:
>
> A new working group for PSR-5 is outlined in PR#1026.
>
> Is it possible to get the PR merged, and an entrance vote initiated to 
> return it to Draft status?
> CRB
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/41e95778-825c-497e-88d1-a143284b9f3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Secretary nomination] Mark Railton

[Alessandro Lai]

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.
>
> Any questions, please do not hesitate to ask.
>
> Mark
>
> On Friday, January 5, 2018 at 7:07:52 PM UTC, Joe Ferguson wrote:
>>
>> I would like to nominate Mark Railton (ma...@markrailton.com) for the 
>> position of FIG Secretary. 
>>
>> Mark has been a part of the Joind.in dev team and has helped out with 
>> Open Sourcing Mental Illness organization.
>>
>> - Phergie Representative
>>
>>
>> -- 
>> - Joe Ferguson
>> JoeFerguson.me
>> MemphisPHP.org
>>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/422abb62-afa7-4db3-bdca-14b85c4f4b9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Console Psr

[Alessandro Lai]

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 07:12:19 UTC+1, Majid abdolhosseini ha 
scritto:
>
> It depends on how you see things.
> If you make abstraction, it's possible,
>
> just consider there is a software (application) which takes some inputs 
> and return output.
> when developing application I don't care how I get inputs (console or web 
> or ...).
>
> I don't care additional inputs are given to process in the middle of 
> processing or at the beginning of process, the important thing is the 
> interface for cli commands, and time is not important when it comes to 
> programming into interface.
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/39f8fe32-5242-40e2-876c-65d3d03594ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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  wrote:
>
>> I am glad to say that I am Chris Tankersley’s sponsor on behalf of 
>> Magento.
>>
>> --
>> 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 post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/3464af7e-f076-4c14-9fb0-a9ed1c74fdae%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Chris Tankersley
> http://ctankersley.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/00d41b9c-f94a-41ab-80d1-01a69e3c27a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Secretary nomination] Robert Parker

[Alessandro Lai]

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 freelancer for 3 years. I want to give back to the PHP community. 
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/5735560e-1be6-4695-8d82-a093db1effd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC nomination] Stefano Torresi

[Alessandro Lai]

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 nominate Stefano Torresi for another term on the Core Committee.
>>
>> Stefano has proven to be a hands-on committee member, working to
>> re-launch the FIG website, participating heavily in working groups,
>> and providing collegial feedback and discussion. I would heartily
>> welcome having him around for another term.
>>
>> --
>> Matthew Weier O'Phinney
>> mweierophin...@gmail.com
>> https://mwop.net/
>>
>> --
>> 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 post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/CAJp_myV9h4QWu_P9R%3DrU%2Bswtrx22LtQtbAgwdr_Y4nYQL1YHWg%40mail.gmail.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/7be4a5af-a43f-437d-a5ac-f29f6b2617fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC nomination] Michael Cullum

[Alessandro Lai]

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 shoes, but I would love to be
> able to continue to contribute to the FIG's goals as a member of the Core 
> Committee.
>
> *A bit of an intro about me:*
> I've been a FIG Secretary for 2 years, during which time I was one of the 
> two main co-authors of the FIG 3.0 specification and
> aided people all across the FIG ecosystem from PSR Editors to Core 
> Committee Members to Project Reps on a variety of
> things as part of my role as FIG Secretary. Before being a PHP FIG 
> Secretary I was the editor of PSR-12, on which I've
> remained part of the working group and I also helped draft a number of 
> bylaws including the one drafting the secretary role.
>
> I also was in a relatively unique position where part of my role was to 
> watch what the community is saying about the PHP FIG on
> Twitter, as well as to advocate for the PHP FIG at conferences and user 
> groups across the globe, and as a result,
> I've spoken to hundreds of people, from lead developers to community 
> contributors to your average Joe developer
> and heard what they have to say about the FIG. I've also had very close 
> contact with our PSR Editors, including those
> of PSRs that are yet-to-come which means I have a good knowledge of the 
> current and many of the future specifications
> the FIG is producing.
>
> Outside the PHP FIG I've been a backend developer for a number of years 
> now, and currently work at SamKnows as
> Lead Technical Architect, mostly doing Big Data and Machine Learning type 
> stuff in PHP and Python. I'm also on the
> core development team of phpBB and am quite closely associated with the 
> Symfony community.
>
> As a result I feel I'm in a good position to be able to represent the 
> community's views on the core committee.
>
> Many thanks,
> Michael C
>
> On Wednesday, 10 January 2018 16:05:40 UTC, Alexander Makarov wrote:
>>
>> 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 different position.
>>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/655397ce-2e36-4587-8353-f99f4bcd52ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

Since site is outdated, it may not have been clear which terms are ending 
and are up for this elections. Those are:

CC members (2016-12-24 - 2018-01-31):
 - Chris Tankersley (@dragonmantank)
 - Graham Hoefer (@greydnls)
 - Korvin Szanto (@korvinszanto)
 - Stefano Torresi (@storresi)

Secretary (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:
>
> Hi all,
>
> The nominations for 4 Core Committee seats and one Secretary position are 
> open; sorry for the delay of this announcement, but I was away from a 
> keyboard for the holidays, and I'm excited to perform my first official 
> duty as a Secretary! I would also like to take the time to thank Michael 
> (whose term as a Secretary is now ending) for such a speedy onboarding for 
> us two newly elected Secretaries, and for the enormous work that he has 
> accomplished in the last two years in our transition to the FIG 3.0. Thanks 
> also to the four CC members whose terms are ending also. 
>
> Below are some practical details and FAQs.
>
> Anyone can be nominated, including the five persons with expiring terms, 
> any Secretaries or project representatives, or any person which would like 
> to be more involved with the FIG.
> ONLY Member projects and Secretaries may nominate, without any limit, to 
> be CC or Secretary candidates.
>
> If you would like to nominate someone, please get in touch with them and 
> speak with them about it first. But please do actively seek out people you 
> think should be on the Core Committee to nominate them, don't wait for them 
> to ask you to nominate them.
>
> If you would like to stand/accept a nomination, please contact the seating 
> secretaries (me, Michael or Margaret) to find out a bit about what the 
> relative role entails. You may seek a nomination any way you wish 
> (requesting on the mailing list, asking individuals in private, etc.).
>
> A list of nominees will be maintained here 
> <https://docs.google.com/spreadsheets/d/1u_Bi2EXJ47iC_xMAUjkJWjz7Gks_BCW15RDXy_qXR9c/edit?usp=sharing>
>  
> . Remember that the nomination must be accepted to be valid, so please 
> ensure that you confirm your nomination if you wish to and someone 
> nominates you.
>
> Nominations close on the 11th January at 23:59 UTC.
>
> FAQs:
>
> What does the role of a CC member entail?
> To quote the Bylaws:
>
> “The Core Committee is a twelve (12) member board of individuals 
> recognized for their technical skill and expertise. The Core Committee is 
> responsible for final decisions regarding what specifications FIG will 
> consider and those that are approved. The Core Committee is responsible for 
> ensuring a high level of quality and consistency amongst all published 
> specifications, and that all relevant perspectives and use cases are given 
> due consideration.”
>
>
> The core committee acts as a steering group and handles all entrance votes 
> and, after being completed by working groups, has the final acceptance vote 
> on new PSRs and is responsible for making sure specifications meet the 
> technical direction of the FIG, are of good quality, and have taken 
> relevant stakeholders into account. The core committee is expected to be 
> able to keep an eye on what is going on in the FIG. While this doesn't mean 
> reading every mailing list post or every GitHub issue, this does mean 
> having a general awareness of what is going on and regular activity is 
> expected (e.g. they should be voting on every core committee two-week vote 
> unless there are particular circumstances preventing them from doing so).
>
> What does the role of a Secretary entail?
> The full role can be read from the bylaws here: 
> http://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>
> Between the three secretaries they handle all the administration that goes 
> on with the FIG such as votes, the website, GitHub as well as also being 
> responsible for moderation of FIG mediums and representing the PHP FIG to 
> the wider PHP community. Feel free to reach out to any of the seating 
> Secretaries if you would like to know more about the role.
>
> What does a Core Committee member look like?
> The idea of the core committee is that it should reflect a cross section 
> of the PHP ecosystem and community.
>
> This means it's important to have a range of people including (but not 
> requiring or limited to) those with experience relating to things such as:
> - Large & small framework maintenance
> - Library maintenance
> - Consumer package maint

[VOTE][Internals] Secretary election

[Alessandro Lai]

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 since today it's possible 
to vote for the renewal of the terms that are up for this elections.

These are the nominations 
results: 
https://docs.google.com/spreadsheets/d/1u_Bi2EXJ47iC_xMAUjkJWjz7Gks_BCW15RDXy_qXR9c/

Since we have 4 unopposed nominations for the CC spots (and the terms are 
all equals, so no sorting is necessary), we will need to vote for the 
secretary position only, for which we have two nominations:

 - Mark Railton https://groups.google.com/forum/#!topic/php-fig/U5eaI90NOsc
 - Robert Parker 
https://groups.google.com/forum/?fromgroups=#!topic/php-fig/BjxM9CVZ3Bg

Full information about the Secretary vote and role is visible in the bylaws 
here: http://www.php-fig.org/bylaws/mission-and-structure/#secretaries 
<http://www.php-fig.org/bylaws/mission-and-structure/#secretaries>

Normally we should use STV, but since we have just one term and two 
candidates, it will be the same if we simply vote with one direct, single 
preference. So, to recap:

*Who can vote?*
As specified in the bylaws, *any Project Representative or Core Committee 
member* is eligible to vote on Secretary candidates.

*When can you vote?*
Voting will be open *until 26th January 23:59 UTC.*

*How to vote*
The voting system used is STV[1][2], so basically, *there is no tactical 
voting possible* (like with FPTP); *vote for who you want*, even if they 
are a less popular candidates as your vote will move down to a different 
candidate if you back an unpopular candidate who doesn't have enough votes; 
if a candidate is elected, their surplus votes are also re-allocated so you 
are not punished for backing popular candidates either. There is no quorum, 
you are of course entitled to not vote and it will not count as a 
missed vote on the voting sheet. *Rank the candidates in order of 
preference *for example*:*

1. Luke
2. Leia
3. Anakin
4. Rey
5. Padmé
6. Finn

At the end of the voting phase 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.org/wiki/Single_transferable_vote

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/efa147fc-ff7c-4537-9e43-3bb4cf3c5249%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/33f97b33-9ed3-4b94-9acb-e50802677e50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 (PhpStorm) and have 
> phpcs constantly in the background too. While working today, I found 
> something odd that I would like to discuss in this list.
>
> I wrote this:
>
> use App\Services\AuditTrail\Actions\{
> ModelPreUpdate,
> ModelPostUpdate,
> ModelCreated,
> ModelDeleted
> };
>
> But phpcs complains that according to PSR-2 I should use this:
>
> use App\Services\AuditTrail\Actions\ModelPreUpdate;
> use App\Services\AuditTrail\Actions\ModelPostUpdate;
> use App\Services\AuditTrail\Actions\ModelCreated;
> use App\Services\AuditTrail\Actions\ModelDeleted;
>
> I looked it up on the PHP-FIG website 
>  and 
> indeed phpcs was right.
>
> Is there a particular reason for this? Seems to me the group use 
> declarations are much more readable and shorter to write/read. 
> Or is this maybe something that was decided pre PHP7 when group use 
> declarations didn't exist?
>
> Just curious to know...
> Cheers!
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/2e99d6cd-8973-4872-af52-7c9cf7b0d111%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Internals] Elections results

[Alessandro Lai]

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 Core Committee members, with terms 
ending in two years from now (2020-01-31):
 - Michael Cullum (newly elected)
 - Chris Tankersley (term renewed)
 - Stefano Torresi (term renewed)
 - Korvin Szanto (term renewed)

As for the secretary election, I've counted the votes, and you can find the 
tally here: 
https://docs.google.com/spreadsheets/d/1wUDQWW06d03EXHiAb67VNhHHePpYMYpXhfjZgNUWqLc/edit?usp=sharing

With 14 votes, the secretary role goes to Mark Railton, congratulations!
I will be in touch with you shortly to welcome you in the new role.

I've also updated the personell.md file in the PHP-FIG repository to 
address these role 
changes: 
https://github.com/php-fig/fig-standards/commit/eff701756667a0ac74206d41ad44fafeaee5c99c
Once we will complete the refactoring of the official site (I hope it's a 
matter of days), that will be reflected by a dedicated page there too.

Thanks to you all!!

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/f5c94d5a-f9bb-4332-a8ec-8139718090bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working Group for PSR-5

[Alessandro Lai]

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 said)
 - a working group (at least 3 other individuals)

Once you have that, your sponsor can call for a CC vote to move PSR-5 back 
into the draft stage (yay!).

Once on draft stage, ping me or my colleagues to move stuff forward (PRs, 
GitHub groups, etc)

Il giorno martedì 30 gennaio 2018 21:34:06 UTC+1, Chuck Burgess ha scritto:
>
> Secretaries,
> I'd like to request taking over as Editor on PSR-5, and request a new Core 
> Committee sponsor as per the new workflow.  I'm not too far off from 
> finishing the preliminary phpdoc3 alpha release steps that I wanted in 
> place before resuming this effort.
> CRB
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/df344c46-24c6-4f7e-a6e5-f0b90e58183a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-11 and Configuration

[Alessandro Lai]

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 UTC+1, Woody Gilk ha scritto:
>
> Having a PSR that defines a configuration interface would be 
> fantastic. It should not replace PSR-11 though. Configuration and 
> containers are completely different things, despite how they might be 
> conflated in various frameworks. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
> On Mon, Feb 12, 2018 at 7:07 PM, Westin Shafer  wrote: 
> > Hey Guys, 
> > 
> > After having built quite a few packages to integrate services into 
> PSR-11 
> > containers, I have to say PSR-11 has made this incredibly nice and IMO 
> has 
> > solved a lot of issues building libraries that just work across 
> different 
> > frameworks.   That said, there is still one issue that has hit me on 
> each of 
> > these libraries getting configuration out of the different containers.   
> As 
> > each framework stores configuration in a different way there seems to be 
> no 
> > uniform way to retrieve it.  This leads to unnecessary implementation 
> > specific code. 
> > 
> > Here's an example of what I mean. 
> > 
> > // Symfony config is parameters. // 
> > if (method_exists($container, 'getParameter') 
> > && method_exists($container, 'hasParameter') 
> > && $container->hasParameter('my-key') 
> > ) { 
> > return $container->getParameter('my-key'); 
> > } 
> > 
> > // Zend uses config key 
> > if ($container->has('config')) { 
> > return $container->get('config')['my-key']; 
> > } 
> > 
> > // Slim Config comes from "settings" 
> > if ($container->has('settings')) { 
> > return $container->get('settings')['my-key']; 
> > } 
> > 
> > 
> > As you can see, this is one area where PSR-11 could use some 
> improvement. 
> > I did see a thread dated few years ago where someone had started a 
> > conversation to address this.   Has there been any movement or other 
> > conversations about this?   If not, is there anything I can do to help 
> move 
> > this conversation forward? 
> > 
> > 
> > Thanks in advance, 
> > Westin Shafer 
> > 
> > -- 
> > 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 post to this group, send email to php-fig@googlegroups.com. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/60bb4c3a-ec94-4081-82d0-2a9f683dcfca%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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d3932819-743a-4033-9ea5-c9e69f892984%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

[Alessandro Lai]

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 months (not the case either, see commits on 
draft: 
https://github.com/php-fig/fig-standards/commits/master/proposed/http-client)

So yes, PSR-18 is not abandoned but in draft stage, as correctly stated in 
our repo/site: https://www.php-fig.org/psr/#draft

Il giorno domenica 18 febbraio 2018 12:28:18 UTC+1, Stefano Torresi ha 
scritto:
>
> As far as I know, PSR-18 has never been marked as abandoned, I don't even 
> think the requirements to do so have ever been satisfied. Could the 
> secretaries confirm, please?
>
> Il giorno gio 15 feb 2018 alle ore 08:47 Tobias Nyholm <
> tobias.nyh...@gmail.com> ha scritto:
>
>> Yeah, it has stalled for a few weeks. but we are working on it again. The 
>> specification looks good, we are currently deciding on an upgrade path from 
>> HTTPlug. We have a proposal that we think will work. I've invited a few to 
>> have a look on it (Sara included). If this small group think it is fine I 
>> will publish it so every one could give their comments. 
>>
>> If no major issues are found I will move the PSR to review. 
>>
>> Den onsdag 14 februari 2018 kl. 13:11:46 UTC+1 skrev Barry vd. Heuvel:
>>>
>>> Apologies, I now see that PSR-18 is referenced in the Sunshine meetings (
>>> https://groups.google.com/forum/#!topic/php-fig/sjASl6ltjHI )


 PSR - 18 HTTP Client (*Abandoned*)

- Tobias identified an issue and will be notifying the group to 
source needed changes.
   - Tobias is waiting on *Sara to offer feedback*.
- This PSR needs 2 implementations to move forward.

 Status abandoned, is that supposed to be Draft? As you are discussing 
>>> the issue with the group. Or are you in search of a new Editor?
>>>
>>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/18d21c1c-508e-479a-8ddd-163291413cc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Internals] Secretary & 4 Core Committee Nominations Open

[Alessandro Lai]

st January: Nominations open
11th January: Nominations close
12th January: Election voting begins
26th January: voting ends
28th January: new CC members and new Secretary take post

Election Process Summary
After nominations close then voting will start. Votes are expressed as an 
ordered list, not as single votes, so you don't have to pick a single 
favorite, but just rate in order of your preference. Member projects can 
vote, as can any community member judged to have participated actively in 
the FIG (there are subjective and objective tests for this in the bylaws, 
which will be taken care of by the seating Secretaries). After the voting 
closes and results are officially announced by me, 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 Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d8609a9d-52df-457d-8b43-70086e961f29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 Core Committee seats and one Secretary position are 
> open; sorry for the delay of this announcement, but I was away from a 
> keyboard for the holidays, and I'm excited to perform my first official 
> duty as a Secretary! I would also like to take the time to thank Michael 
> (whose term as a Secretary is now ending) for such a speedy onboarding for 
> us two newly elected Secretaries, and for the enormous work that he has 
> accomplished in the last two years in our transition to the FIG 3.0. Thanks 
> also to the four CC members whose terms are ending also. 
>
> Below are some practical details and FAQs.
>
> Anyone can be nominated, including the five persons with expiring terms, 
> any Secretaries or project representatives, or any person which would like 
> to be more involved with the FIG.
> ONLY Member projects and Secretaries may nominate, without any limit, to 
> be CC or Secretary candidates.
>
> If you would like to nominate someone, please get in touch with them and 
> speak with them about it first. But please do actively seek out people you 
> think should be on the Core Committee to nominate them, don't wait for them 
> to ask you to nominate them.
>
> If you would like to stand/accept a nomination, please contact the seating 
> secretaries (me, Michael or Margaret) to find out a bit about what the 
> relative role entails. You may seek a nomination any way you wish 
> (requesting on the mailing list, asking individuals in private, etc.).
>
> A list of nominees will be maintained here 
> <https://docs.google.com/spreadsheets/d/1u_Bi2EXJ47iC_xMAUjkJWjz7Gks_BCW15RDXy_qXR9c/edit?usp=sharing>
>  
> . Remember that the nomination must be accepted to be valid, so please 
> ensure that you confirm your nomination if you wish to and someone 
> nominates you.
>
> Nominations close on the 11th January at 23:59 UTC.
>
> FAQs:
>
> What does the role of a CC member entail?
> To quote the Bylaws:
>
> “The Core Committee is a twelve (12) member board of individuals 
> recognized for their technical skill and expertise. The Core Committee is 
> responsible for final decisions regarding what specifications FIG will 
> consider and those that are approved. The Core Committee is responsible for 
> ensuring a high level of quality and consistency amongst all published 
> specifications, and that all relevant perspectives and use cases are given 
> due consideration.”
>
>
> The core committee acts as a steering group and handles all entrance votes 
> and, after being completed by working groups, has the final acceptance vote 
> on new PSRs and is responsible for making sure specifications meet the 
> technical direction of the FIG, are of good quality, and have taken 
> relevant stakeholders into account. The core committee is expected to be 
> able to keep an eye on what is going on in the FIG. While this doesn't mean 
> reading every mailing list post or every GitHub issue, this does mean 
> having a general awareness of what is going on and regular activity is 
> expected (e.g. they should be voting on every core committee two-week vote 
> unless there are particular circumstances preventing them from doing so).
>
> What does the role of a Secretary entail?
> The full role can be read from the bylaws here: 
> http://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>
> Between the three secretaries they handle all the administration that goes 
> on with the FIG such as votes, the website, GitHub as well as also being 
> responsible for moderation of FIG mediums and representing the PHP FIG to 
> the wider PHP community. Feel free to reach out to any of the seating 
> Secretaries if you would like to know more about the role.
>
> What does a Core Committee member look like?
> The idea of the core committee is that it should reflect a cross section 
> of the PHP ecosystem and community.
>
> This means it's important to have a range of people including (but not 
> requiring or limited to) those with experience relating to things such as:
> - Large & small framework maintenance
> - Library maintenance
> - Consumer package maintenance (by consumer package I mean CMS, blogs, 
> forums, etc.)
> - HTTP and non-HTTP based PHP
> - Legacy and modern projects
> - PHP internals
> - Specific topics such as Async and Security
>
> However, it is important to note that you are voting for people, not 
> projects, so please do not vote in people because t

Re: Secretary Elections - Nominations Needed!

[Alessandro Lai]

Hi! Can you please present yourself (name and something else) so we can 
nominate you? Thanks!

Il giorno mercoledì 1 agosto 2018 07:14:53 UTC+2, designc...@gmail.com ha 
scritto:
>
> If there's room, I'd like to get a nomination as well. I don't know anyone 
> in the PSR space personally, but I've been actively using PSR interfaces, 
> most notably in my recently launched BitFrame PHP Microframework 
> <https://www.bitframephp.com/>. Since I'm actively developing BitFrame 
> and its components, and using PSRs on the regular, I think I could add to 
> the community 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 by Alessandro Lai and 
>> the seat recently vacated by Mark Railton. 
>>
>>
>> Whilst Alessandro Lai's term is over, they are more than welcome to 
>> stand for re-election although other people may also, and are needed to, 
>> also stand. 
>>
>>
>> Should Alessandro be leaving us then on behalf of the FIG as a whole I’d 
>> like to thank him for all that they’ve done and contributed to the PHP 
>> FIG and also to take this opportunity to ask them not to leave and instead 
>> to stand for re election and continue to do so very much of the work and in 
>> fact will offer them bribes of stickers and candy should they find such 
>> things persuasive.
>>
>> Anyone wishing to stand for secretary must be nominated (details below) 
>> by the *August 4th* at which point a vote will occur.
>>
>> Nomination, details on the role and voting information: 
>> https://github.com/php-fig/fig-standards/blob/master/bylaws/003-membership.md#fig-secretary
>>
>> Nominations must be provided by *existing voting members* or *FIG 
>> secretaries* and nominations may be sought by potential candidates by 
>> whatever means necessary (request to the mailing list, contacting 
>> individuals in private etc.). Please, don't nominate someone without first 
>> checking with them.
>>
>> Timetable:
>>
>>- 
>>
>>Nominations are open from *now* until the end of *August 3rd*.
>>- 
>>
>>Voting will be from *August 4th* until the *August 18th*
>>- 
>>
>>The secretary will then take office on the last Sunday of the month 
>> (*August 
>>26th*)
>>
>>
>> If anyone would like more information on what’s involved, or has any 
>> other questions, feel free to contact me or Alessandro (i...@php-fig.org 
>> goes to both of us).
>>
>> TL;DR: Nominations are now open for someone to take the vacant third 
>> secretary position.
>>
>>
>> Now, please go find us some great candidates!
>>
>>
>> Best,
>>
>>
>> Margaret
>>
>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/3c882e22-9cdd-4558-b7a4-5f4c835897e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Internal] CC elections result

[Alessandro Lai]

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 Gary which stepped down a few 
months ago. The official date to take office is this sunday, the 26th; I'll 
update the site in a bit.

Congratulations on all of you!

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/771b801c-63d5-4b35-9309-8f6fc6eddc39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Phalcon] Voting member change request

[Alessandro Lai]

We've received confirmation by one other of the core Phalcon team, we are 
proceeding with this 
change: 
https://github.com/php-fig/fig-standards/commit/69a0b05f24f699e904546df7f5d8b57db54cad80

Il giorno venerdì 10 agosto 2018 22:57:59 UTC+2, Nikolaos Dimopoulos ha 
scritto:
>
> Hey Margaret
>
> Thank you for the prompt reply. I will post on our discord server to send 
> you their replies.
>
> /vr Nikos
>
> On Friday, August 10, 2018 at 1:33:49 PM UTC-4, Dead Lugosi wrote:
>>
>> Hi Nikos,
>>
>> I've reached out to other folks on the Phalcon team. 
>>
>> If they can confirm that this change is the consensus of the group, or if 
>> Andres gets back to us to name you as a replacement, we'll make the change.
>>
>> Best,
>>
>> Margaret
>>
>>
>> On Wed, Aug 8, 2018 at 8:46 AM 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 Friday, June 15, 2018 at 4:34:31 AM UTC-4, Alessandro Lai wrote:
>>>>
>>>> Hello Nikolaos!
>>>> Unfortunately our bylaws require a confirmation from the previous 
>>>> representative; is he unable to do that? How long will he be unreachable?
>>>>
>>>> Keep in mind that the next elections will be held in August.
>>>>
>>>> Il giorno giovedì 14 giugno 2018 19:11:47 UTC+2, Nikolaos Dimopoulos ha 
>>>> scritto:
>>>>>
>>>>> Greetings PHP-FIG.
>>>>>
>>>>> I am one of the members of the core team for Phalcon (
>>>>> https://phalconphp.com/en/team)
>>>>>
>>>>> Our colleague Andres (current voting member) is currently taking some 
>>>>> much needed time off, therefore I was wondering if I can become a voting 
>>>>> member until he returns.
>>>>>
>>>>> Thank you for your consideration
>>>>>
>>>>> /vr Nikos
>>>>>
>>>> -- 
>>> 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/92d7e848-21ee-4bb9-8929-1803806c6a36%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/php-fig/92d7e848-21ee-4bb9-8929-1803806c6a36%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/172b9bb2-b7f7-4190-973c-19deacfd28e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Abandoned PSR-5

[Alessandro Lai]

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 Working group; 
also refer to the previous discussion 
here: https://groups.google.com/forum/?fromgroups#!topic/php-fig/bcV4KXIW6dQ

Thank you!

Il giorno venerdì 16 marzo 2018 04:33:01 UTC+1, Joe T. ha scritto:
>
> Interest here as well. Basically on stand-by waiting for further 
> instruction.
>
> -joe
>
>
> On Thursday, 15 March 2018 14:33:50 UTC-4, Chuck Burgess wrote:
>>
>> Hey Alice,
>>
>> I'm slowly trying to form a Working Group in order to resurrect PSR-5.
>>
>> CRB
>>
>>
>> On Mar 15, 2018 13:28, "Alice Wonder"  wrote:
>>
>> Is there any desire to bring something like PSR-5 back?
>>
>> There are two reasons why I think there should be some standards related 
>> to the doc block.
>>
>> A) For legal reasons, every file needs to have author(s) and license 
>> specified in a way that it can be programmatically retrieved.
>>
>> File level comment with @author and @license seems to be the defacto way 
>> that is done.
>>
>> B) Code analysis tools often use function comment blocks to determine 
>> what type a parameter should be and what type the output should be. Psalm 
>> is a good tool for doing that, and since I started using Psalm it has found 
>> many bugs of mine that I otherwise would never have triggered myself but I 
>> could see how someone using my classes might.
>>
>> But there is some confusion there. I usually specify the types as they 
>> would be used in type hinting (e.g. bool or int) but some standards want 
>> those same types expressed as boolean or integer. vimeo/psalm seems to like 
>> the way I do it, may work with the other I don't know, but that's where a 
>> standard like PSR-5 would be useful. It could specify how to indicate the 
>> type and then both code analysis tools and programmers can follow the spec.
>>
>> For the most part I think the old PEAR standard is good and most of my 
>> checking is done against that, but I just wanted to express that at least 
>> one user would be very interested in something like PSR-5 existing.
>>
>> Thank you for your time.
>>
>> -- 
>> 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/27026c23-9142-432b-88ad-7f99a87fecde%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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/4d636c10-7d09-4048-b799-861537370697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stepping down from CC

[Alessandro Lai]

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: 
https://www.php-fig.org/bylaws/elections-and-vacancies/#core-committee-vacancy

Il giorno mercoledì 4 aprile 2018 14:50:34 UTC+2, GeeH ha scritto:
>
> Hi Folks,
>
> Effective immediately I'm stepping down from my role on the core committee 
> - I've done nothing at all to help the group and would prefer my spot go to 
> someone who can contribute.
>
> Regards,
>
> Gary
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/3118dc22-170d-4a69-a9c3-0dd19d29e8df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 Monday, April 9, 2018 at 12:01:51 AM UTC-4, Larry Garfield wrote:
>>
>> I  hereby call an Entrance Vote to restart PSR-14, Event Dispatcher. 
>>
>> The proposed working group is as follows: 
>>
>> Editor:  Larry Garfield 
>>
>> Sponsor: Cees-Jan Kiewiet 
>>
>> Other Group Members: 
>>
>> Elizabeth Smith 
>> Benjamin Mack 
>> Matthew Weier O'Phinney 
>> Ryan Weaver 
>>
>> The revised scope and charter is in this PR: 
>>
>> https://github.com/php-fig/fig-standards/pull/1016 
>>
>> This is an Entrance Vote only, so it's a vote to say "yes, we should have 
>> one" 
>> rather than a statement on any particular implementation detail. 
>>
>> This vote is open to Core Committee members only.  Everyone else, please 
>> hold 
>> your horses. :-)  Please give a +1/-1.  The vote is open until 23 April 
>> or 
>> until all 11 CC members have voted, whichever comes first. 
>>
>> --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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/c14235f9-a861-45ca-afc6-0206adad74bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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."

https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md#3-declare-statements-namespace-and-import-statements

Il giorno lunedì 23 aprile 2018 04:24:10 UTC+2, Joe T. ha scritto:
>
> i'm not in the WG, but i always restrict to 1 blank line between any two 
> structures - aside from line after opening *{* and before closing *}* 
> where no blank line is permitted. Extra blank lines feel like something 
> wasn't finished. It's just... ew.
> -jlt
>
>
> On Sunday, 22 April 2018 19:52:02 UTC-4, Greg Sherwood wrote:
>>
>> Hi,
>>
>> I wrote the PSR-1 and PSR-2 standards for PHP_CodeSniffer and I'm now 
>> writing a PSR-12 standard as well. I have a question about this section:
>>
>> 4.2 Using traits
>>> ...
>>> When the class has nothing after the use import statement, the class 
>>> closing brace MUST be on the next line after the use import statement.
>>> ...
>>> Otherwise it MUST have a blank line after the use import statement.
>>>
>>> >>
>>> namespace Vendor\Package;
>>>
>>> use Vendor\Package\FirstTrait;
>>>
>>> class ClassName
>>> {
>>> use FirstTrait;
>>>
>>> private $property;
>>> }
>>
>>
>> The rule states that the use import statement must have a blank like 
>> after it, but should PHPCS enforce a single blank line or at least one 
>> blank line? Is this valid code?
>>
>> >
>> namespace Vendor\Package;
>>
>> use Vendor\Package\FirstTrait;
>>
>> class ClassName
>> {
>> use FirstTrait;
>>
>>
>>
>>
>> private $property;
>> }
>>
>> Thanks
>>
>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/65e70798-df7f-4e73-a4df-2e4ae5fd24f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please make new pkgist release of PSR-16

[Alessandro Lai]

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 one uses
>
>"require": {
> "psr/simple-cache": "^1.0"
> }
>
> The result when using vimeo/psalm to check the code has errors because of 
> a bug in the 1.0.0 release that is fixed in master but not fixed in a 
> released version:
>
> expecting 'null|int|Psr\SimpleCache\DateInterval'
>
> The doc block bug is fixed in master but a stable release was never made 
> that contains the fix.
>
>   
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d21bc98f-8ed6-4de6-991f-9a269fa1c7c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Service provider PSR: discussing the scope

[Alessandro Lai]

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 help or more 
details.

Il giorno domenica 4 marzo 2018 21:10:06 UTC+1, Matthieu Napoli ha scritto:
>
> Using the container for configuration is not (imho) the purpose of 
>> containers and makes it harder to standardize on using FQCN for container 
>> identifiers.
>
>
> I don't think it's limited to configuration. You'd have the same 
> (non-)issue with config-less containers.
>
> Matthieu
>  
>
>> On Sat, Mar 3, 2018, 15:18 Oscar Otero  wrote:
>>
>>> To me, the problem with these proposals is they have different 
>>> responsabilities in the same class. A ServiceProvider implementation 
>>> includes the callables to create instances of different services, defines 
>>> the key used to store each of these services and even include two methods: 
>>> one to get factories and other for extensions, so in many times you have to 
>>> create a method returning an empty array (see 
>>> https://github.com/container-interop/service-provider/issues/43), 
>>> (Interface segregation principle).
>>>
>>> I proposed a different approach (
>>> https://github.com/container-interop/service-provider/issues/45) 
>>> consisting in creating a factory for each service. The proposal is just a 
>>> sketch to illustrate the main concept (each object has just one 
>>> responsabiity: create a service) and surely can be improved.
>>>
>>>
>>>
>>> El 3 mar 2018, a las 14:07, David Négrier  
>>> escribió:
>>>
>>> To build upon Larry's answer, the container does not only contains 
>>> services. It knows how to build them.
>>>
>>> If we ended up "setting" in a container every service, well first... we 
>>> could use arrays instead of containers :) and then, the performance of the 
>>> container would degrade proportionally to the number of entries in the 
>>> container. You would have to instantiate and store every service on every 
>>> request, even if the service does not end up being called. So basically, 
>>> the bigest your application, the slowest.
>>>
>>> This is why both proposals carefully avoid the use of a "set" method.
>>>
>>> ++
>>> David.
>>>
>>>
>>> Le vendredi 2 mars 2018 23:02:49 UTC+1, Larry Garfield a écrit :

 The reason a simple set() won't work is that the "thing" put into the 
 container is generally not a value but instructions for how to produce 
 a value 
 on-demand, and the value is typically a service object.  How to encode 
 "here's 
 how to build the thing" is the main question to answer. 

 --Larry Garfield 

 On Friday, March 2, 2018 1:18:32 PM CST David Lundgren wrote: 
 > If the problem to solve is "what's a common way to put things in a 
 > container?" wouldn't the simplest solution be a `set($id, $value)` 
 method 
 > on the container? 
 > 
 > Most container implementations already have a method of this sort. 
 While a 
 > few have shared/concrete/protected concepts baked in, they could make
  
 > separate methods for changing it  based on the $id. 
 > 
 > Dave 
 > 
 > On Thursday, March 1, 2018 at 11:16:29 AM UTC-6, David Négrier wrote:
  
 > > Hey list, 
 > > 
 > > We are still in the process of forming a working group regarding a 
 Service 
 > > provider PSR. 
 > > 
 > > I've had the chance to speak about this with several Symfony 
 contributors, 
 > > and while discussing about this idea, Nicolas Grekas 
 > >  (from Symfony) came up with an
  
 > > alternative proposal. It's about having many containers working 
 together, 
 > > with a slightly different scope. First of all, I'd like to thank 
 Nicolas 
 > > for the time he is investing in researching this issue, and for all 
 the 
 > > feedback. We talked about his idea with Matthieu Napoli 
 > >  and Larry Garfield 
 > >  at the Paris ForumPHP in November. I'm 
 now 
 > > sharing this conversation with you. 
 > > 
 > > I put this in a blog article that you can find here: 
 > >
 https://thecodingmachine.io/psr-11-scope-of-universal-service-providers
  
 > > 
 > > I'm reposting the content of the article here, since it's directly 
 related 
 > > to PHP-FIG concerns. It's a bit long, but the topic is worth it :) 
 > > 
 > > Stated goal 
 > > 
 > > Each framework has it's own custom package format (bundles, 
 packages, 
 > > modules, etc...). What these package formats are doing is 
 essentially 
 > > always the same. They are used to put things in a container. 
 > > 

Re: Integration of JS and CSS

[Alessandro Lai]

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, that would solve even better your needs, with a 
nice packing of CSS and JS 
together: https://symfony.com/doc/current/frontend.html

Il giorno lunedì 5 marzo 2018 01:07:33 UTC+1, Alice Wonder ha scritto:
>
> What I am going to do is create a reference implementation for a class 
> that adds JavaScript and CSS to a document that will allow third party 
> JS/CSS to be packaged separately.
>
> My reference class itself will not be of benefit to 99% of the world 
> because it will use DOMDocument but from it, hopefully it will demonstrate 
> what a standard interface could be like, and then if such as PSR is ever 
> standardized I could then port the reference class to actually implement 
> what is agreed upon.
>
> Bundling 3rd part JS/CSS into an app for production deployment though is 
> just fundamentally wrong IMHO and right now that's what has to be done for 
> both composer and RPM installs.
>
> On Sunday, March 4, 2018 at 3:13:24 PM UTC-8, Alice Wonder wrote:
>>
>> Yes I am extremely familiar with RPM and have been packaging RPMs since 
>> the Red Hat 6.0 days (pre Fedora)
>>
>> But they don't address this issue. For example, the RPMs that exist for 
>> roundcube mail include jQuery and other 3rd party JS in the roundcube RPM 
>> itself because their is no standard way to for roundcube to say it needs 
>> jQuery X.
>>
>> PHP class dependencies can be in separate packages thanks to autoloaders, 
>> but not the JavaScript
>>
>> On Thursday, March 1, 2018 at 5:29:39 PM UTC-8, Alice Wonder wrote:
>>>
>>> Hello,
>>>
>>> I have a php class that generates an HTML5 audio player with support for 
>>> WebVTT captions and chapters and is very accessible.
>>>
>>> It's a personal class, I am not distributing it as FLOSS and I probably 
>>> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an 
>>> external file, I do not allow the style attribute in my code) and its own 
>>> webfont that is used kind of like an image sprite but better IMHO than 
>>> using an image sprite (for the interface buttons).
>>>
>>> Anyway one of the things that literally bothers me about so many web 
>>> applications is they bundle scripts many of which (e.g. jQuery) are third 
>>> party to the web application.
>>>
>>> I was thinking it would be good for something *like* PSR-4 to exist for 
>>> non-php resources.
>>>
>>> What I mean is Web Application A requires jQuery >= 3 but doesn't need 
>>> to bundle it itself, where the bundled often often becomes stale.
>>>
>>> Instead there could be a PSR class interface defined so that when the 
>>> web application needs to add jQuery to the (x)html document head - it could 
>>> call
>>>
>>> $whatever::addJavaScript("jQuery:jQuery", "3.0");
>>>
>>> Class $whatever would then look in virtual vendor namespace "jQuery" for 
>>> a script that meets the name definition of "jQuery" with minimum version 
>>> "3.0" and returns the appropriate URI to add to the script node.
>>>
>>> For people who use composer it may not make much difference, they will 
>>> end up with stale version over time (or initially if a composer.lock file 
>>> is used) just like they often end up with stale unpatched vulnerable 
>>> versions of class libraries - but for those who actually update their 
>>> installs periodically (or use an actual package manager which composer is 
>>> not) it could be of a great benefit.
>>>
>>> I already do something similar for my own private web apps, it could 
>>> IMHO be a huge benefit if there was a standardized way of doing it.
>>>
>>> Thoughts?
>>>
>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a421a13d-3646-4f5c-8235-8fdd6c73d02d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 giorno lunedì 12 febbraio 2018 17:41:10 UTC+1, Larry Garfield ha scritto:
>
> After further refinement, the PSR-6 errata are, I think, ready again.  For 
> formality's sake I am hereby opening another 2 week review period before 
> calling another vote. 
>
> https://github.com/php-fig/fig-standards/pull/915 
>
> The vote will be called sometime on or shortly after 26 February. 
>
> If any further discussion is needed, please do so in this thread before 
> then. 
>
> --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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/c181020d-0fa3-41ca-8fc0-6c8295e3bd98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 21:58:26 UTC+2, Michael Cullum ha scritto:
>
> +1
>
> On Wed, 24 Oct 2018, 6:59 am Cees-Jan Kiewiet,  wrote:
>
>> +1
>>
>> On Tue, Oct 23, 2018 at 4:28 PM Lukas Kahwe Smith  
>> wrote:
>>
>>> +1 
>>>
>>> regards,
>>> Lukas
>>>
>>> > On 21 Oct 2018, at 18:05, Larry Garfield  
>>> wrote:
>>> > 
>>> > +1
>>> > 
>>> > --Larry Garfield
>>> > 
>>> >> On Sunday, October 14, 2018 9:46:40 AM CDT Sara Golemon wrote:
>>> >> The REVIEW period for the proposed PSR-18, HTTP Clients, hit its 
>>> minimum
>>> >> required length on 19 September 2018. We continued the period since 
>>> then to
>>> >> iron out additional clarifications to the specification, which have 
>>> all
>>> >> since been merged.
>>> >> 
>>> >> At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the
>>> >> acceptance vote is limited to Core Committee members. The vote will 
>>> close
>>> >> either at 23:59:59 UTC on 28 October 2018, or when all CC members 
>>> have cast
>>> >> their vote, whichever comes earlier.
>>> >> 
>>> >> The relevant materials are as follows:
>>> >> 
>>> >> - Specification:
>>> >> 
>>> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/ht
>>> >> tp-client.md - Metadocument:
>>> >> 
>>> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/ht
>>> >> tp-client-meta.md
>>> >> 
>>> >> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
>>> >> Current CC Members are as follows:
>>> >> 
>>> >> Beau Simensen
>>> >> Larry Garfield
>>> >> Matthew Weier O’Phinney
>>> >> Sara Golemon
>>> >> Cees-Jan Kiewiet
>>> >> Lukas Kahwe Smith
>>> >> Samantha Quiñones
>>> >> Chris Tankersley
>>> >> Korvin Szanto
>>> >> Stefano Torresi
>>> >> Michael Cullum
>>> >> Chuck Burgess
>>> >> 
>>> >> -Sara
>>> > 
>>> > -- 
>>> > 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 post to this group, send email to php-fig@googlegroups.com.
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/php-fig/3316062.MSLtbGGoY2%40vulcan.
>>> > 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to php-fig@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/php-fig/228D8791-42B2-44A0-9186-FA481071950D%40pooteeweet.org
>>> .
>>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/CAPY1sU8WPNFQiDpc2KxbDzoxvTCT_q69oxe3DMroj5_gfcDxTA%40mail.gmail.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/58b7f78a-aba3-4c45-833b-3b3d1b75a982%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 settembre 2018 00:28:29 UTC+2, Mark Baker ha scritto:
>
> Just as an outsider looking at PSR-12 (Extended Coding Style Guide) with a 
> couple of suggestions:
>
> Namespace separators
>
> There shouldn't be any whitespace around a namespace separator, wherever 
> it is used. PHP permits this, but it can be less inutive to read
>
> Increment/Decrement Operators
>
> There shouldn't be any whitespace between the increment/decrement 
> operators, ad the variable being incremented/decremented. This can cause 
> difficulty reading code, especially where the arithmetic plus/minus 
> operators as used within the same expression.
>
> $a ++ + ++ $a
>
> I've not seen reference to either of these cases in the style PSRs
>
> -- 
> Mark Baker
>
>  _
> |.  \ \-3
> |_J_/ PHP |
> || |  __  |
> || |m|  |m|
>
>  I LOVE PHP
>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/474c5e4f-9f56-4407-bffc-6132c439c5eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 Things(tm). 
>   
> Thank you to everyone that filled out the survey from last week; the 
> results 
> were strongly in favor of keeping the current naming pattern, so that's 
> what 
> we're going to do. 
>
> I have gone ahead and split up the spec into 3 packages as discussed, and 
> per 
> the first poll.  There are now 4 packages in total, all of which are now 
> registered on Packagist.  (Thanks for Alessandro for getting that wired 
> up.) 
>
> https://github.com/php-fig/event-dispatcher 
> https://github.com/php-fig/event-dispatcher-message 
> https://github.com/php-fig/event-dispatcher-task 
> https://github.com/php-fig/event-dispatcher-util 
>
> The text of all 3 spec packages is also now integrated into the spec 
> itself 
> (or will be as soon as a last PR is merged): 
>
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md
>  
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
>  
>
> All packages have been tagged with 0.6.0. 
>
> *If you want to try out the Event Dispatcher spec yourself, now is the 
> perfect 
> time to do so!*  Just add a require statement for the 0.6.0 tag of the 
> appropriate repositor[y|ies] and go to town.  If the spec is unclear in 
> some 
> way that makes it difficult for you to figure out what to do, please tell 
> us!   
> That's exactly the sort of feedback we want to have.  (Well, we'd rather 
> hear 
> that it's all self-explanatory and perfect, but if it's not then we want 
> to 
> know that, too.) 
>
> We're going to let it sit for a little bit longer while a few other 
> parties 
> take it for a spin.  Barring anything cropping up that we don't currently 
> anticipate, expect a Readiness Vote to be called in about 1-2 weeks. 
>
> --Larry Garfield 
> PSR-14 Editor

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8085ba34-d397-4275-acd0-a58f2e8d3cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b40c31cc-fbd6-41e2-ab74-cba7a1e9a596%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 if PhpStorm / PHPStan / etc have 
> looked at syntaxes for this use case?
> CRB
> *about.me/ashnazg *
>
>
> On Mon, Nov 12, 2018 at 11:38 AM Woody Gilk  wrote:
>
>> Could we use:
>>
>> @return iterable
>>
>> ?
>>
>> Also generators can return key => value:
>>
>> @return iterable
>>
>> Would imply:
>>
>> yield $key => $user;
>>
>> --
>> Woody Gilk
>> https://shadowhand.me
>>
>>
>> On Mon, Nov 12, 2018 at 11:34 AM Larry Garfield  
>> wrote:
>>
>>> On Monday, November 12, 2018 10:06:08 AM CST Chuck Burgess wrote:
>>> > So here we do indeed have a special IDE implementation to try to deal 
>>> with
>>> > the OP's kind of use case.
>>> > 
>>> > Again, I can't envision a more standardized way to solve this with tags
>>> > themselves.
>>> > 
>>> > 
>>> > I'll mention this again, with regard to this use case though:
>>> > Stepping back a moment... that /* @var */ usage... seems like I've only
>>> > ever seen that used to typehint the $item portion of the example, not 
>>> the
>>> > $stream portion... $stream should have been figured out earlier when 
>>> it was
>>> > first populated, either by its own /* @var */ doc or by the return 
>>> type of
>>> > whatever function/method actually populated it.
>>> > 
>>> > Would using the /* @var */ in this manner not solve this use case?
>>> > CRB
>>> > *about.me/ashnazg *
>>>
>>> I agree that, when putting a @var over a foreach, only the $item is 
>>> really 
>>> relevant to document.
>>>
>>> My use case may be tangential/related, as I'm talking more about how to 
>>> specify "iterable of X" in "the return type of whatever function/method 
>>> actually populated it".
>>>
>>> While it would be lovely to say that [] implies any "collection", I 
>>> don't 
>>> think PHP will let us do that.  Arrays and iterables are not 
>>> interchangeable, 
>>> as there's a few dozen functions that work on arrays but not iterables.
>>>
>>> To wit:
>>>
>>> /**
>>>  * @return int[]
>>>  */
>>> function foo() : iterable {
>>>
>>> }
>>>
>>> int[] implies "Array of ints", which means calling array_* functions on 
>>> it is 
>>> a totally legit thing to do.  But what's returned is an iterable, which 
>>> means 
>>> there's no guarantee that it's an array; it could return any 
>>> Traversable, or 
>>> foo() could be a generator itself.  In those cases, the docblock is now 
>>> materially wrong and misleading.
>>>
>>> I'm not sure what the best solution here is, but I do think we need one.
>>>
>>> (And that's before we get into the excitement of an iterable that 
>>> returns non-
>>> numeric keys, which is also completely valid, so we have to think about 
>>> something like Go maps, yeaa!)
>>>
>>> --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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to php-fig@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/php-fig/39547303.NTl641kpUQ%40vulcan.
>>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BV8Da%3Dc_%3Di2Rq%3D5Vq8uQ6%2BvX7sdnoVeq%2BKZde5of7DEg%40mail.gmail.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a42101d4-1b94-47f2-9304-6cc890a96abf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 doing that: breaking SemVer would be 
a very bad example here.

I'm all for splitting it into a separate package, but I would like the CC 
input on this, since my previous action seems to be debatable. In any case, 
this would require a 2.0 of psr/log, but I fear that that change would 
scare a lot of people... Even the 1.1 ruffed some feathers!

Il giorno venerdì 7 dicembre 2018 20:23:42 UTC+1, Larry Garfield ha scritto:
>
> On Friday, December 7, 2018 10:19:45 AM CST Rasmus Schultz wrote: 
> > I noticed the introduction of two PHPUnit-specific test-dependencies 
> into 
> > the psr/log package: 
> > 
> > https://github.com/php-fig/log/tree/1.1.0/Psr/Log/Test 
> > 
> > How is this in any way acceptable? 
> > 
> > The dependency isn't even declared in the "composer.json" file - but 
> that's 
> > kind of besides the point. 
> > 
> > First of all, PHPUnit isn't PHP - introducing facilities for a specific 
> > test-framework is extremely opinionated and does not belong in an 
> package 
> > with interfaces designed to bridge projects and provide interoperability 
> > between different frameworks. (PHPUnit being a test-framework.) 
> > 
> > Moreover, these facilities aren't a dependency, at all - you can use 
> this 
> > package just fine without it. There is no rational reason not to package 
> > these dependencies separately. 
> > 
> > These facilities belong in a different package that depends on psr/log, 
> so 
> > you can version them separately. Stuffing these into the package itself 
> is 
> > extremely controversial and could create a serious problem with 
> versioning. 
> > (having to version the interfaces as 2.0 for a breaking change to the 
> > test-facilities!) 
> > 
> > I'm calling for a bugfix release to remove these ASAP. 
> > 
> > Who's even responsible for this? 
> > 
> > There's no issue-tracker on the GitHub project, and I don't see any 
> > discussion about it in this forum. 
> > 
> > wtf? 
>
> One of them has been there for years.  The other was just added recently 
> with 
> little notice. 
>
> This has been discussed before, and frankly I agree that the tests should 
> not 
> be in the package at all.  We have -util packages for this sort of thing. 
>
> Related discussion: 
>
> https://github.com/php-fig/log/pull/52#issuecomment-378323725 
>
> --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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/ed94acf6-698c-4410-8b10-44dba2f40ef7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12] Casting variable section

[Alessandro Lai]

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 statements
>
> case 2:
>
> $var =(bool)$var1;
>
> // although this might from other section related with assignment of 
> variable...
>
> case 3:
> ( bool ) $var === true
>
> // I think this is not covered from any section
>
> Τη Παρασκευή, 28 Δεκεμβρίου 2018 - 5:07:21 μ.μ. UTC+2, ο χρήστης Georgios 
> Mponos έγραψε:
>>
>> Hello,
>>
>> I am writing this thread in order to notify you about casting issues that 
>> got into my attention. I think that PSR-12 is not dealing with how the 
>> casting should be styled
>>
>> https://github.com/squizlabs/PHP_CodeSniffer/pull/2331
>>
>> Also one more thing that could be useful is this:
>>
>> https://github.com/doctrine/coding-standard/pull/100
>>
>> I believe that PSR-12 should deal with spaces inside of cast and spaces 
>> before the cast.
>>
>> Regards,
>>
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/687f77fc-9436-4f3b-b5f2-661c98cc4230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 Kiewiet wrote:
>>
>> At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the  
>> acceptance vote is limited to Core Committee members. The vote will close 
>> either at 23:59:59 UTC on 24 March 2019, or when all CC members have cast 
>> their vote, whichever comes first. 
>>
>> Sara Golemon
>>
>> +1 
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/09336d6f-1af8-4998-93d0-e7d335d9da1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[INTERNAL] Core Committee & Secretary nominations open

[Alessandro Lai]

vote, as can any community member judged to have participated actively in 
the FIG (there are subjective and objective tests for this in the bylaws, 
which will be taken care of by the seating Secretaries). After the voting 
closes and results are officially announced by me, 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 Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/27b3aa8d-886b-478d-a067-5fba78373a64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 you, that good, otherwise 
we secretaries can call a vote on that.

Il giorno domenica 17 febbraio 2019 00:01:44 UTC+1, Buster Neece ha scritto:
>
> Regarding the purpose of my original message, there are a list of PHP 
> projects, both frameworks and larger web applications, that are associated 
> with PHP-FIG listed on the group's web site as "Member Projects": 
> https://www.php-fig.org/personnel/
>
> I'm interested in possibly adding my project to this list and filling the 
> capacity as the project's representative in matters relating to PHP-FIG 
> operations. As far as my understanding of the posted by-laws goes, this 
> also confers some eligibility to serve on working groups and limited voting 
> on proposed standards.
>
> While I'm also aware that the by-laws state that any application for 
> project membership into PHP-FIG must be sponsored by a current project or 
> by a Core Committee member, I was directed to this mailing list as a good 
> place to introduce myself and express my interest in general.
>
> I have long been both an implementer and vocal supporter of the PSR 
> standards, but it was only recently that some of the members of the 
> organization talked about it on social media and got me particularly 
> interested in participating in some capacity.
>
> I apologize if this isn't the correct venue for expressing interest, but I 
> would greatly appreciate if anyone could direct me on next steps to take at 
> this point.
>
>  - Buster Neece
>
>
> On Wednesday, February 13, 2019 at 7:43:39 AM UTC-6, Alexander Makarov 
> wrote:
>>
>> 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 peers!
>>>
>>> My name is Buster Neece, and I am the creator and primary maintainer of 
>>> a free and open-source web radio management suite named AzuraCast (
>>> https://azuracast.com/). AzuraCast is a predominantly PHP web 
>>> application combined with the infrastructure and setup tools necessary to 
>>> provide a turnkey "web radio in a box" experience for self-hosted station 
>>> operators. The underlying application is based on our own library 
>>> (AzuraCore) which extends and integrates the Slim PHP microframework, the 
>>> Doctrine ORM and other components. Across the application, we implement and 
>>> strongly support a number of existing PSR standards.
>>>
>>> As an end-user-facing application rather than a developer-oriented tool, 
>>> our popularity on GitHub isn't entirely representative of our installed 
>>> user base out on the web, which numbers in the tens of thousands at this 
>>> point and is growing at a significant rate.
>>>
>>> I'm unclear if there are any thresholds in the PHP-FIG organization for 
>>> the size or adoption rate of a project such that it merits joining PHP-FIG 
>>> as a member project, but it would be an honor and a privilege to help be 
>>> involved in any capacity with this immensely valuable organization.
>>>
>>> Thank you for your time and consideration!
>>>
>>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8680380f-33b0-4cf0-bc96-cde7686eb0c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

+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 unless you are listed as a member of the 
> working group. A +1 vote means that you support moving forward into review, 
> and a -1 means that you think the working group should discuss this more.
>
> As this is a readiness vote, quorum will be 50% and a majority of at least 
> 2/3 is required for passage. Though I hope to see a unanimous decision 
> before we continue.
>
> --
> The current working group for PSR-12 is as follows:
>
> Editor:
> Korvin Szanto
>
> Sponsor:
> Chris Tankersley
>
> Members:
> Alexander Makarov
> Michael Cullum
> Robert Deutz
>
> Please do not reply to this thread unless your name is listed above.
>
> Thanks,
> Korvin
>
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a7c68135-873b-4809-b7a5-e85fc56f639d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][Nomination] Woody Gilk

[Alessandro Lai]

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 Gilk over the course of developing both 
>> PSR-15 and PSR-17. He has proven to be an excellent collaborator, and 
>> willing to work towards consensus decisions. Woody has strong review 
>> skills, and is able to predict usage problems with accuracy.
>>
>> I think Woody's skills would be a strong fit for the Core Committee, and 
>> I hereby nominate him.
>>
>> -- 
>> Matthew Weier O'Phinney
>> mweierophin...@gmail.com
>> https://mwop.net/
>> he/him
>>
>> -- 
>> 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 post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/CAJp_myX7rvt8AGZnCAvwxes0WXTgqF6KJ3rg9it3j0qa1Dt2cw%40mail.gmail.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/31de54a4-f027-4ed9-9600-9218e770d16a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][Nomination] Larry Garfield

[Alessandro Lai]

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, Cees-Jan Kiewiet wrote: 
> > As Larry has been doing an outstanding job in the FIG over the years 
> > I'm hereby nominating Larry Garfield for the Core Committee. 
> > 
> >  -- 
> >  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 post to this group, send email to php-fig@googlegroups.com. 
> >  To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/3288a071-7a4f-4384-9cf3-f469134baf70%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/php-fig/3288a071-7a4f-4384-9cf3-f469134baf70%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> >  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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/7eeb834f-3ef2-4e5d-b38a-9b256593d794%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

rs to both a text representation and a 
> slugified one.
>
> In hindsight, I think the IETF naming convention has *heavy* negative 
> trade-offs. Some will argue that it's a good naming scheme, but I think we 
> can agree that trying to remember what RFC is about what is a waste of 
> neurons. We have had it easy because we only had to deprecate one standard, 
> PSR-2, but, believe it or not, I have seen people still getting confused 
> about this, because someone would refer to a spec as "the autoloader PSR", 
> to only later mention the actual version, leading to undesirable "gotchas".
> Considering that if we had to keep the pace with the engine development 
> cycle, in the worst case we would need to release a new version every two 
> years, simply using natural numbers to identify standards would quickly 
> become a mess. Also, we can't make it match with Semver major versions, and 
> this should be enough to prove it ineffective as a versioning scheme.
> The main reason for introducing a separate concept from the Composer 
> version is because Composer doesn't allow for multiple versions of the same 
> package to coexist.
> That said, using the major Semver number in the namespace would allow very 
> straight forward migration paths, avoiding the Python scenario: we could 
> produce backwards compatible adapters for newer Revisions, that could 
> coexist with previous ones, actively encouraging adoption of the new and 
> deprecation of the old.
> Separating it from the PSR number allows unambiguous and clear naming, 
> ensuring that a specification will successfully endure the test of time 
> without causing headaches, contrary to things like RFC2616.
> Omitting the Revision for V1 allows for a cleaner transition from the 
> current status quo, and avoids unnecessary verbosity for standards that 
> would hardly be ever updated because of inherent characteristics.
> Bundling documents *with* the sources I think just makes sense, I can't 
> imagine why they should continue to be separated. If someone wants to 
> implement a spec, they will just have to require the package and open the 
> included markdown in the vendor dir, which they will be *sure* it matches 
> the interfaces they are trying to implement.
>
> On a side note, I would also take the chance to rename the topic of some 
> of the current PSRs, because sometimes we have a pleonastic "Interfaces" in 
> the name that just drives me crazy, but hey, that's just me.
>
> So how do we release this stuff?
>
> Simple enough: different repos for each PSR, for each Revision. A new 
> Revision is a fork of the previous one. If a PR is opened to a current PSR 
> but it requires a new Revision, it should be straightforward to retarget it 
> to a new fork, once the due voting process is done. The WG members will be 
> maintainers of all the repos of a PSR. This should also make it *much 
> easier* the governance of the access and the contribution process, which I 
> reckon it hasn't always been exactly seamless with the current flow (e.g. 
> sometimes PRs have been hanging for a lot of time because the Editor or 
> anyone in the WG was not notified, or they needed approval from the 
> secretaries, etc).
>
> 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.
>
> This is all I got for now, I realise that there may be unclear details, 
> but at least we started a discussion on this problem.
>
> I know for a fact that some people won't approve any of this, so I'll 
> now let you throw figurative milk shakes at me.
>
> Cheers,
> Stefano
>
> Il giorno gio 6 giu 2019 alle ore 16:14 Matthew Weier O'Phinney <
> mweierophin...@gmail.com> ha scritto:
>
>>
>>
>> On Thu, Jun 6, 2019 at 4:16 AM Alessandro Lai  
>> wrote:
>>
>>> 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 received in the past. This is because the PSRs, as 
>>> standards, should be immutable, and they cannot be changed meaningfully, 
>>> apart from small erratas. 
>>>
>>> I would like to change that.
>>>
>>> This is a topic that many times surfaced in our chats, but we never 
>>> tried to solve it. The release schedule

[BYLAW] Proposal: let PSRs evolve with the language

[Alessandro Lai]

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 received in the past. This is because the PSRs, as 
standards, should be immutable, and they cannot be changed meaningfully, 
apart from small erratas. 

I would like to change that.

This is a topic that many times surfaced in our chats, but we never tried 
to solve it. The release schedule of the language is a lot more tight and 
fast compared to the past, and we need to keep up the pace, to avoid that 
our PSRs become obsolete in a matter of years.

My proposal is simple but limited; I didn't work on a full text change of 
our bylaws, but before I delve in the technicalities I would like to try 
and explain my idea succinctly, to see if I have some consensus about it.

This is the summary of my proposal:
 - PSRs packages can receive new major releases
 - new majors should be used just to improve the code, so that it can use 
new language features (types, return type, void, \Throwable...)
 - the new major should never break the spec
 - implementors should be able to easily support all majors of the package 
(AKA "psr/*": "^1.0|^2.0"); even more, it should be recommended
 - if possible, the additions to the spec should just be added to implement 
in code something from the spec that before wasn't expressible before (like 
exceptions interfaces extending `\Throwable`)
 - a changelog should be appended to the PSR to reflect the changes in the 
new version
 - the process to make this happen should be:
 -- PR to the PSR
 -- demonstrate straightforward cross-compat between version
 -- editor approval, calls a CC vote
 -- CC vote with 2/3 majority

What do you think? Do you think this is doable?

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/89341907-fca6-448a-a887-531d0f7b6a89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Internal] Election results

[Alessandro Lai]

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 late; I've used OpenSTV to 
calculate the outcome, and I've pasted the output at the end of this email. 
The elected are, in order of preference:

 - Woody Gilk
 - Larry Garfield
 - Matthew Weier O'Phinney
 - Matteo Beccati
 - Beau Simensen

Beau, as last elected, will take the shorter term; all the others will take 
the normal two-year term. All of them will be taking post this weekend, as 
per our bylaws.
This is the PR that updates the personnel page accordingly: 
https://github.com/php-fig/fig-standards/pull/1169

Thank you to all that participated in any way, and good luck to all the 
newly elected!

OpenSTV output:

Ballot file contains 7 candidates and 13 ballots.
No candidates have withdrawn.
Ballot file contains 13 non-empty ballots.

Counting votes for PHP-FIG Core Committee May 2019 elections using ERS97 
STV.
7 candidates running for 5 seats.

 R|Woody |Larry |Adam  |Matthew   |Matteo|Beau  |Benni  
   |Exhausted |Surplus   |Threshold 

 1|  1.00|  5.00|  0.00|  4.00|  2.00|  1.00|  
0.00|  0.00|  4.66|  2.17
  
|-
  | Count of first choices. The initial quota is 2.17. Candidates Larry and 
Matthew have reached the threshold
  | and are elected. Candidates have surplus votes so surplus votes will be 
transferred for the next round.

 2|  1.00|  2.17|  0.00|  4.00|  3.12|  2.12|  
0.56|  0.03|  2.78|  2.16
  
|-
  | Count after transferring surplus votes from Larry. Candidate Matteo has 
reached the threshold and is
  | elected. Candidates have surplus votes so surplus votes will be 
transferred for the next round.

 3|  2.35|  2.17|  0.45|  2.17|  3.12|  2.12|  
0.56|  0.06|  1.13|  2.13
  
|-
  | Count after transferring surplus votes from Matthew. Candidate Woody 
has reached the threshold and is
  | elected. Candidates have surplus votes so surplus votes will be 
transferred for the next round.

 4|  2.35|  2.17|  0.45|  2.17|  2.17|  2.12|  
1.50|  0.07|  0.18|  2.13
  
|-
  | Count after transferring surplus votes from Matteo. Candidates have 
surplus votes, but since candidates can
  | be safely eliminated, the transfer of surplus votes will be delayed and 
candidates will be eliminated and
  | their votes transferred for the next round.

 5|  2.35|  2.17|  |  2.17|  2.17|  2.12|  
1.95|  0.07|  0.18|  2.13
  
|-
  | All losing candidates are eliminated. Count after substage 1 of 1 of 
eliminating Adam. Transferred votes
  | with value 0.45. Candidates have surplus votes so surplus votes will be 
transferred for the next round.

 6|  2.17|  2.17|  |  2.17|  2.17|  2.24|  
2.01|  0.07|  0.07|  2.13
  
|-
  | Count after transferring surplus votes from Woody. Candidate Beau has 
reached the threshold and is elected.

Winners are Woody, Larry, Matthew, Matteo, and Beau.

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view 

Re: [PSR-12] Arrow Functions

[Alessandro Lai]

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:
>
> 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?
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/9b6297e5-8cc8-4ef7-a29d-17712d55b5f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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:
>
>> The URI MUST be complete and well-formed as specified in RFC 2396.
>>
>> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#description-5
>>
>> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#description-11
>
>
> this rfc is of year 1998 and is a DRAFT standard that itself confirms that 
> it's been obsoleted by the newer rfc
>
>> Obsoleted by: 3986DRAFT STANDARD
>> https://tools.ietf.org/html/rfc2396
>
>
> the rfc 3986 is of 2005 year and pretends to have an INTERNET STANDARD 
> status:
>
>> Updated by: 6874, 7320 INTERNET STANDARD
>> Obsoletes: 2732, 2396, 1808  L. Masinter
>> https://tools.ietf.org/html/rfc3986
>
>
> definitely, the psr has to refer to the newer one, not to the obsolete
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/baf3d1a2-a985-4c56-a198-51043e7931a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC][Nomination] Adam Englander

[Alessandro Lai]

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 
(https://joindin.wordpress.com/2019/02/04/new-joind-in-leadership-team/) as 
a security responsible party member, and he would like to lend a hand here 
in the PHP-FIG too.

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/da8673db-a745-419a-a5e1-441a78d793aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][Nomination] Adam Englander

[Alessandro Lai]

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 unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/0236e302-a028-4caa-b5c4-7038611709c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC][]Nomination] Beau Simensen

[Alessandro Lai]

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 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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/382e757c-bbb3-4bed-8b67-3d61a50a6805%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 O'Phinney (
>> https://twitter.com/mwop 
>> )
>>  
>> for the upcoming Core Committee Election.
>>
>> Matthew has been a long-standing member of the PHP-FIG, both as a project 
>> representative and as a current Core Committee member. He has been involved 
>> with the PHP community for many, many years, and directly worked on both 
>> PSR-0 and PSR-7 as editor, and coordinator on PSR-11 and PSR-13. His work 
>> as project lead for the Zend Framework (soon Laminas) has given him a good 
>> look into how frameworks can interact and work together, and how developers 
>> use the PHP-FIG's PSRs.
>>
>> -Chris
>> [image: Sent from Mailspring] 
>>
>> -- 
>> 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 post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/754A7090-1136-4F47-BA10-2CEACCF92B37%40getmailspring.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/him
>

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8a29b1c7-9e36-45f6-9bbd-d4415a04d13b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC][NOMINATION] Matteo Beccati

[Alessandro Lai]

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 and the 
PHPDay conference.

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d2b01d08-74c0-427a-a53f-6783c1f4667d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Secretary][NOMINATION] Asmir Mustafic

[Alessandro Lai]

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 new major 
version, and by reflection he contributed a lot to the PHP community, in 
related projects too (see https://github.com/goetas).

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/9b717f5f-d914-4c61-a820-99a6903d51b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[VOTE] Core Committee Election

[Alessandro Lai]

Hello everyone,
as specified in the previous thread 
(https://groups.google.com/d/topic/php-fig/SSGn1VJtOJs/discussion), 
yesterday at midnight the nominations ended, and since today it's possible 
to vote for the renewal of the terms that are up for this elections.

We have *5 spots on the Core Committee* up for reelection, four with a full 
two year term and a shorter one, that will end in August 2020, due to Lukas 
stepping down; we also have one full-term spot for secretary.
Since we have only one unopposed nomination for the secretary election, we 
will need to vote for the Core Committee positions only, for which we have 
seven nominations (listed in chronological order of nomination):

 - Woody Gilk 
https://groups.google.com/d/topic/php-fig/DaoLQAiykpc/discussion
 - Larry Garfield 
https://groups.google.com/d/topic/php-fig/HqtrPuUI_YQ/discussion
 - Adam Englander 
https://groups.google.com/d/topic/php-fig/3TjKW8MmBks/discussion
 - Matthew Weier O'Phinney 
https://groups.google.com/d/topic/php-fig/PAnOZqE4QiQ/discussion
 - Matteo Beccati 
https://groups.google.com/d/topic/php-fig/Mahn59nAmbU/discussion
 - Beau Simensen 
https://groups.google.com/d/topic/php-fig/v1cPGmMT430/discussion
 - Benni Mack 
https://groups.google.com/d/topic/php-fig/wVIhtZNVgmM/discussion

Full information about the Core Committee vote and role is visible in the 
bylaws here: 
https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee

*Who can vote?*
As specified in the bylaws, any Project Representative or any participant 
in the PHP-FIG ML can vote on the CC elections. A ML participant is defined 
in the bylaws as follows:
"Any individual that has posted a non-trivial message in the official FIG 
venue (mailing list, forum, etc.) at least five (5) times within the past 
calendar year as of the start of nominations [...] is eligible to vote on 
Core Committee candidates."

 
*When can you vote?*
Voting will be open in this thread until May 19th 23:59 UTC.

*How to vote*
The voting system used is STV[1][2], so basically, there is no tactical 
voting possible (like with FPTP); vote for who you want, even if they are a 
less popular candidates as your vote will move down to a different 
candidate if you back an unpopular candidate who doesn't have enough votes; 
if a candidate is elected, their surplus votes are also re-allocated so you 
are not punished for backing popular candidates either. There is no quorum, 
you are of course entitled to not vote and it will not count as a missed 
vote on the voting sheet. Rank the candidates in order of preference for 
example:

1. Luke
2. Leia
3. Anakin
4. Rey
5. Padmé
6. Finn

At the end of the voting 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 Explanation 
https://www.youtube.com/watch?v=l8XOZJkozfI
[2]: https://en.wikipedia.org/wiki/Single_transferable_vote

-- 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/9e1624fa-b968-43c6-923f-5d507774703e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC][Nomination] Benni Mack

[Alessandro Lai]

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 
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/9621caee-ad50-4609-8890-08856f85bef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Lai]

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 interested in Stefano's proposal, but I have one doubt: using 
> this namespace strategy, it seems to me that a consumer of the spec can 
> only require one revision at a time, is that correct (and desired)?
>
> Il giorno giovedì 6 giugno 2019 23:11:05 UTC+2, Stefano Torresi ha scritto:
>>
>> Hey list,
>>
>> First of all, thanks Alessandro for bringing this up.
>> I have given a lot of thought on this topic, which, as most of you will 
>> know, has been recurring pretty much since PHP7 was released.
>> I never actually sat down and write these thoughts of mine, though, so I 
>> better do it now, finally.
>>
>> While I agree that something *must* be done to ease the process of 
>> keeping PSRs up to date, I think the suggested approach is too simplistic 
>> and would introduce more problems than it solves.
>>
>> There are multiple facets to this issue, here are some we need to solve 
>> to fully address it:
>> - The common Git workflow of opening a PR doesn't really fit a project 
>> that is meant be immutable once released, bar minor erratas that can't 
>> effectively harm users.
>> - The specification documents are separate from the actual code, if any; 
>> I think this is exactly why simply opening a PR, voting it, and merging may 
>> seem easy, but it's actually not. If we update the interfaces and release a 
>> new version of the Composer package, we also need to update the specs, and 
>> vice-versa. While updating the package is a simple as bumping a tag, 
>> updating the specification documents has no actual release process instead, 
>> because a new PSR is supposed to be created instead. We can't simply make 
>> the old specification documents disappear by merging a PR. Also, superseded 
>> major versions should still be accessible for future reference.
>> - All specs are all in the same repository, so their lifecycle cannot be 
>> managed independently.
>> - The namespace of the code we produce (Psr\Foo\Bar and Fig\Bar\Baz) is 
>> fragmented, ambiguous and wouldn't accommodate multiple major version of 
>> the same PSR living in the same codebase. This makes effectively impossible 
>> to provide soft migration paths from one version to another, which would 
>> probably end up in a Python 3 scenario, where not enough people will 
>> migrate to the new ones to simply declare the old one DEAD, thus incurring 
>> in the risk of very long and painful transition timeframes where multiple 
>> incompatible standards are used in the wild.
>>
>> Now, at the cost of sounding preposterous, I will propose the following:
>> *I think we need to completely overhaul **our naming conventions, **the 
>> PSR release process (just the release, not the production workflow!), and 
>> how we use VCS to manage the documents and sources we produce. This 
>> involves a lot of changes and the willingness to turn page quite 
>> drastically.*
>>
>> Here comes some craziness, but bear with me.
>>
>> We could overhaul the naming scheme by introducing the concept of 
>> Revisions:
>>
>> Standard name: PSR-$n - $topic [ - Revision $major.$minor.$patch]
>> Package name: fig/psr-$n-$topic[-rev-$major]:$major.$minor.$path
>> Namespace: Fig\Psr$n[\Rev$major]\
>> URI: php-fig.org/psr/psr-$n-$topic[-rev-$major] 
>> <http://php-fig.org/psr/psr-$n-$topic%5B-rev-$major%5D>
>>
>> Example 1:
>> PSR-7 - HTTP Messages - Revision 1.0.0
>> Package name: fig/psr-7-http-messages:1.0.0  
>> Namespace: Fig\Psr7\  
>> URI: php-fig.org/psr/psr-7-http-messages
>>
>> Example 2:
>> PSR-7 -  HTTP Messages - Revision 2.0.0
>> Package name: fig/psr-7-http-messages-rev-2:2.0.0  
>> Namespace: Fig\Psr7\Rev2\  
>> URI: php-fig.org/psr/psr-7-http-messages-rev-2
>>
>> Example 3:
>> PSR-7 -  HTTP Messages - Revision 2.0.1
>> Package name: fig/psr-7-http-messages-rev-2:2.0.1
>> Namespace: Fig\Psr7\Rev2\  
>> URI: php-fig.org/psr/psr-7-http-messages-rev-2
>>
>> Note that:
>> - The Revision number matches the Semver package version, but it's 
>> doesn't map exactly to the same concept. The most relevant part is 
>> obviously the major number because minor and patch should not break 
>> compatibility, thus releasing a new Revision will not be required.
>> - If the Revision is omitted, 

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

[Alessandro Lai]

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:

https://docs.google.com/spreadsheets/d/1QY7AUVQbWnVCbOZqJX11tbz2gKr-pU0CeZezcyJsEPA

It's basically a double-entry table with all the combinations of 
with/without argument/return types, on both sides (interface & concrete 
implementation); I've linked 3v4l pages for all the entries, except the 
trivial ones on the diagonal where interface and implementation match 
perfectly.

As you can see it's quite the minefield, and trying to add only the return 
type to the interface (column D) is a complete disaster, as it's broken in 
all cases except a perfect match; but I've highlighted in green what seems 
to me a good upgrade path, both on the PSR side, that for the 
implementation. The path is as follows:

psr/log v1, as we know it: log($level, $message, array $context = [])
psr/log v2, adds argument types: log(string $level, string $message, array 
$context = []); (REQUIRES PHP 7.2)
psr/log v3, adds both types: log(string $level, string $message, array 
$context = []): void; (REQUIRES PHP 7.2)

Monolog v1 (as released): compatible with both psr/log v1 & v2
Monolog v2 (as released, adds return type): compatible with all psr/log 
versions
Monolog v3 (adds both return and arguments types): compatible with both 
psr/log v2 & v3

So, basically every version from Monolog is compatible with at least two 
adjacent versions of the interface. This seems to me a perfect upgrade 
path, that would require a new PSR only for the last step, because PSR-3 
would be compatible with v1 and v2, and PSR-3-next would be declared 
compatible with v2 and v3. This would mean no need to change package and/or 
namespaces, the interface would remain the same, it would just evolve 
through SemVer with a "bridge" version between the two (nearly identical) 
PSRs. Obviously PSR-3 would require an amendment, but it would just to 
declare the compatibility with the bridge version, and announce the future 
deprecation in favor of the new one.

If this seems reasonable to you, tomorrow I'll try to draft a PR to the 
bylaws to have an actual text to discuss over.

Il giorno mercoledì 18 settembre 2019 21:07:39 UTC+2, Cees-Jan Kiewiet ha 
scritto:
>
> EHLO,
>
> From a consumers perspective the namespaced revisions sounds like hell to 
> me to be honest. As a consumer I care about the highlevel 
> Psr\Log\LoggerInterface interface, not whether it's rev1, 2, or 35. To me 
> the packages for each PSR should be handled like any other PHP package and 
> receive major new versions introduction updates/maintenance for that 
> package. And as a consequence only one version of a PSR should be active, 
> like PSR-12 supersedes PSR-2 or PSR-4 supersedes PSR-0. This means that 
> consumers should always be moving forward, but at their own pace. Even 
> though PSR-0 is deprecated you can still use it in composer today.
>
> For example we do a follow up on PSR-3 adding (return) type hints. We 
> would deprecated PSR-3 in favour of the new PSR, tag v2.0.0 on the psr/log 
> package and watch as all package maintainers slowly upgrade their packages 
> to the new PSR. At some point all packages you use in your projects will 
> have upgraded and you can upgrade to PSR-3NEXT. (Dependabot is a great tool 
> to automate that.)
>
> This is the way is goes with any package, whether it's a small library or 
> a mayor framework. I don't see why our PSR's should be any different from 
> the already unwritten conventions and ways of working in the community. Yes 
> that means it might take a while before you can upgrade, and yes that means 
> effort from package maintainers to update and release a new version. But we 
> as a community can help with that. 
>
> With all respect to you and your idea Stefano but it feels like a 
> bureaucrats way of solving a developer problem. This problem IMHO needs a 
> very simple solution, not a one that will complicate the ecosystem over 
> time. And I'm afraid that with using versioned namespaces and package names 
> will lead to more fragmentation. The beauty of having these PSR's is that 
> you can rely on everything in your application behaving the same way. And 
> tbh I really don't want two different PSR-7's in my applications, I want 
> one where I can rely on that everything in the applications follows that 
> specific version of the spec.
>
> On Wed, Sep 18, 2019 at 5:52 PM Stefano Torresi  
> wrote:
>
>> Hey Ale,
>>
>> Can we push this forward somehow?
>>>
>>
>> My proposal didn't receive much feedback tbh, but nobody proposed 
>> alternatives.
>>
>>
>> I have one doubt: using this namespace strategy, it seems to me that a 
 consumer of the spec can only require one revision at a time, is that 
 correct (and desired)?

>>>
>> Nope, that's quite the opposite: having the revision in the namespace 

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

[Alessandro Lai]

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 compatible with both psr/log 
and Monolog to work.

As shown in the table, if the package adds only argument types, it will be 
broken in any upstream version combination that is working on itself, and 
that's bad. But if it adds the return type first, following Monolog's 
example, all is fine; the only downside is that adding argument types too 
would break compat with Monolog v2, regardless of psr/log version.

So, to summarize, the upgrade path of this downstream package would be:

Version N:
psr/log: ^1.0
monolog/monolog: ^1.0

Version N+1: adds return type like Monolog v2, will use v2 only if PHP >= 
7.2
psr/log: ^1.0|^2.0
monolog/monolog: ^1.0|^2.0

Version N+2: add argument types too:
psr/log: ^2.0|^3.0
monolog/monolog: ^3.0

This IMHO would make releasing version N+2 very unlikely in the short term, 
due to not having cross compatibility with 2 major versions of Monolog at 
the same time.

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/3f1a68ef-b5ed-4005-8b0d-667dbbc8a73a%40googlegroups.com.

Re: Revert inappropriate PSR-12 post-vote merge

[Alessandro Lai]

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 
scritto:
>
> Hi Everyone,
> I totally agree that merging #1183 was an overstep on my part, the bylaws 
> are clear that it should be a secretary managing merging and not the editor 
> of the PSR. I also agree that some of these changes would qualify for 
> errata, I appreciate you paying attention and holding me accountable.
>
> That said I think our bylaws are a little too open when it comes to 
> managing these sorts of changes. Once a PSR is accepted, secretaries are 
> charged with managing "typos, changes or errata" with the optional help of 
> the editor: 
> > If the Acceptance Vote passes, ... the Working Group is automatically 
> dissolved, however the Editor’s input (or a nominated individual 
> communicated to the secretaries) may be called upon in the future should 
> typos, changes or Errata on the specification be raised.
>
> The "typos" and "changes" portion of that is classified more specifically 
> in the Amendments bylaw as "formatting and typo" fixes:
>
> > If formatting is broken for any reason then changing formatting must not 
> be considered a change to the document. These can be merged or pushed 
> without hesitation by a secretary, as long as they don’t change anything of 
> any meaning or syntax.
>
> So secretaries are expected to ensure modifications are "not ... 
> considered a change to the document" and "don’t change anything of any 
> meaning or syntax" with the occasional help of the Editor as needed. In 
> practice, as demonstrated here these things are subjective and can be 
> interpreted differently by different individuals. In this case, both the 
> Editor of the PSR and current secretaries looked at these changes and 
> agreed they could be merged without errata votes.
>
> I think we should consider changing the typos and formatting change 
> process so that it's less subjective and more likely to result in stable 
> specifications. Perhaps we could have a subcommittee in the CC that has to 
> give blessing to merge changes to any approved specification.
>
> Thanks again for keeping an eye on these things Larry,
> Korvin
>
> On Wed, Sep 18, 2019 at 9:42 AM Larry Garfield  
> wrote:
>
>> Hi all.
>>
>> I noticed this morning that this PRs had been merged against PSR-12:
>>
>> https://github.com/php-fig/fig-standards/pull/1185
>> https://github.com/php-fig/fig-standards/pull/1183
>>
>> I do not believe the changes in them are appropriate for an 
>> already-voted-on PSR.  Changes post-vote are permitted in only very narrow 
>> circumstances:
>>
>> https://www.php-fig.org/bylaws/psr-amendments/#3-acceptable-amendments
>>
>> The following changes in that PR go well beyond Annotations or Formatting 
>> & Typos:
>>
>> https://github.com/php-fig/fig-standards/pull/1185/files
>>
>> Changing "would not" (a non-binding term) to a "MUST NOT" (an RFC defined 
>> term with very specific meaning) is a substantive change.  The original 
>> "Would not" language is, in context, entirely adequate.
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L99
>>
>> This block changes the meaning of the spec, and thus is not allowed.
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L369
>>
>> Because capitalized MUST has a specific "legal" meaning, this is also 
>> technically a substantive change.
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L439
>>
>> Substantive change, and isn't even explained.
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L464
>>
>> While this is a net-zero impact change because the language already 
>> requires it, I would still say it's more than is allowed without an errata.
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L689
>>
>> These buts don't really add anything.  (Insert inappropriate joke here.)
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L885
>>
>> This change is even noted in the comments as being a substantive change.  
>> This is not acceptable post-vote.
>>
>>
>> https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9R918
>>
>> I... don't even know what this is about at all.
>>
>> As a result, what is currently published as PSR-12 is not what was 
>> approved by the Core Committee.  That situation must be corrected.
>>
>> I ask the Secretaries to revert both PRs promptly. Additionally, I do not 
>> believe PRs to approved specs should be merged by anyone other than the 
>> Secretaries, as they are the ones 

[VOTE][PROJECTS][BYLAW] PSR evolution

[Alessandro Lai]

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 working on this draft 
after a long discussion here on the ML 
(https://groups.google.com/d/topic/php-fig/OyC3plRYhqg/discussion), after 
that the issue surfaced many times on our communication channels. 

The PR has been reviewed by multiple parties, and I consider it now ready 
to be put to a vote. So I hereby call a bylaw vote, following following our 
Voting Protocol: 

https://www.php-fig.org/bylaws/voting-protocol/

THIS THREAD IS FOR VOTES OF PROJECT REPRESENTATIVES ONLY; any other message 
or "vote" will be ignored. As always, you can vote with a +1, +0 or -1, you 
will have a period of two weeks to cast your vote, so this will be closed 
after 23:59:59 UTC of Monday 25th.

There is no quorum for this vote, and a 2/3 majority is required for it to 
pass.

Thank you.

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/fc771d51-13e8-411f-8b0e-eae400f92897%40googlegroups.com.

[VOTE][CC][BYLAW] PSR evolution

[Alessandro Lai]

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 working on this draft 
after a long discussion here on the ML 
(https://groups.google.com/d/topic/php-fig/OyC3plRYhqg/discussion), after 
that the issue surfaced many times on our communication channels. 

The PR has been reviewed by multiple parties, and I consider it now ready 
to be put to a vote. So I hereby call a bylaw vote, following our Voting 
Protocol: 

https://www.php-fig.org/bylaws/voting-protocol/

THIS THREAD IS FOR VOTES OF THE CORE COMMITTEE ONLY; there will be another 
thread for Project Representative; any other message or "vote" will be 
ignored. As always, you can vote with a +1, +0 or -1, you will have a 
period of two weeks to cast your vote, so this will be closed after 
23:59:59 UTC of Monday 25th.

There is a 50% quorum for this vote, and a 2/3 majority is required for it 
to pass.

Thank you.

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/c2879540-00c4-4dcd-b4d9-6c4fba50c8fc%40googlegroups.com.

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

[Alessandro Lai]

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:
>>
>> 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 working on this draft 
>> after a long discussion here on the ML (
>> https://groups.google.com/d/topic/php-fig/OyC3plRYhqg/discussion), after 
>> that the issue surfaced many times on our communication channels. 
>>
>> The PR has been reviewed by multiple parties, and I consider it now ready 
>> to be put to a vote. So I hereby call a bylaw vote, following our Voting 
>> Protocol: 
>>
>> https://www.php-fig.org/bylaws/voting-protocol/
>>
>> THIS THREAD IS FOR VOTES OF THE CORE COMMITTEE ONLY; there will be 
>> another thread for Project Representative; any other message or "vote" will 
>> be ignored. As always, you can vote with a +1, +0 or -1, you will have a 
>> period of two weeks to cast your vote, so this will be closed after 
>> 23:59:59 UTC of Monday 25th.
>>
>> There is a 50% quorum for this vote, and a 2/3 majority is required for 
>> it to pass.
>>
>> Thank you.
>>
>>

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/73371a85-22f1-47c5-87ee-5130529db9ef%40googlegroups.com.

Re: PSR-17: HttpFactoryInterface maybe?

[Alessandro Lai]

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 martedì 12 novembre 2019 10:55:45 UTC+1, Alexander Makarow ha 
scritto:
>
> What do you mean by autodetect?
>
> There are interfaces for factories already. You can type hint as 
> necessary, you can replace implementation. It already promotes creating 
> message via individual interfaces such as ResponseFactoryInterface. It's 
> not a good idea to inject general HttpFactoryInterface and then use only 
> one part of its methods. It violates single responsibility principle.
>
> вт, 12 нояб. 2019 г., 01:14 Daniyal Hamid :
>
>> @Alexander Makarow asked: "What would be the benefit having it? "
>>
>> So, the problem this would solve is; imagine a use case, for example with 
>> a static http factory that tries to auto-detect an http factory 
>> implementation (such as Nyholms' or Guzzles'). Having an 
>> HttpFactoryInterface would serve the following benefit in such a use-case:
>>
>> 1. If the developer wanted to add his own factory, the 
>> HttpFactoryInterface would allow type hinting;
>> 2. We could ensure an HttpMessageFactory implementation always has all 
>> the required factory methods to create http message related classes;
>> 3. Implementations (such as Nyholms' or Guzzles') could easily be 
>> swappable;
>> 4. It promotes ease of use for creating http messages.
>>
>> PS: @alexander Sorry, I ended up creating a duplicate post, the one you 
>> replied to I deleted, so I'm posting the reply here.
>>
>> On Monday, November 11, 2019 at 11:32:23 PM UTC+1, Daniyal Hamid wrote:
>>>
>>> Hi,
>>>
>>> I was wondering if it would be a good idea to create an 
>>> HttpFactoryInterface class that basically is an amalgamation of all PSR-17 
>>> interfaces, something like:
>>>
>>> interface HttpFactoryInterface extends 
>>> RequestFactoryInterface, 
>>> ResponseFactoryInterface, 
>>> ServerRequestFactoryInterface, 
>>> StreamFactoryInterface, 
>>> UploadedFileFactoryInterface, 
>>> UriFactoryInterface 
>>> {
>>> }
>>>
>>>
>>>
>>> Guzzle 
>>>  and Nyholm 
>>>  
>>> already 
>>> have HttpFactories as such so maybe it's a good idea to add such an 
>>> interface?
>>>
>> -- 
>> 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 visit 
>> https://groups.google.com/d/msgid/php-fig/f4f25988-528d-4b81-be83-d74d8898b3e6%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/dd3022ad-c155-4df7-837f-e664cf1203f5%40googlegroups.com.

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

[Alessandro Lai]

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 giorno mercoledì 16 ottobre 2019 10:38:59 UTC+2, Anton Fedonjuk ha 
scritto:
>
> See my previous comment to Matthew Weier O'Phinney, can u do this? If u 
> cant this disscussion is mistification.
>
> вторник, 15 октября 2019 г., 22:39:58 UTC+3 пользователь Alexandru 
> Pătrănescu написал:
>
>>
>> The pattern that PSR-7 promote is the use of immutable objects.
>> It is maybe a bit harder to use, in some peoples opinion, but on the long 
>> run it reduces the number of bugs in a software.
>> Maintaining (unnecessary) state is a source of increased maintenance cost 
>> (bugs or harder to change code).
>>
>>

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/3261c76a-9ab1-49aa-be0c-7c732f7fd457%40googlegroups.com.

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

[Alessandro Lai]

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 the second step (with return types) is IMHO the good step 
forward then, because it would push the standard forward, accompanying any 
library that would add return types, maybe thanks to PHP 7.4 too.

Il giorno sabato 5 ottobre 2019 15:21:47 UTC+2, G. P. B. ha scritto:
>
> Greetings PHP-FIG,
>
>
> From my understanding this project is to add parameter and return types to 
> some of the interfaces defined in PSRs before those exists in PHP.
>
>
> First, adding parameter types is the easiest and also, in my mind, the 
> most important type information to add, as it is impossible to add a more 
> specific type from a mixed type as it goes against LSP.
> This is easy to add as it doesn't break compatibility with current 
> implementations, as parameter types can be widened. 
> Adding parameter types can be tagged as a version 1.1.0 because semver 
> allows to upgrade dependencies in minor version. i.e. updating the PHP 
> version is a dependency update.
>
> Determining whether the change is a patch level or minor level 
>> modification depends on whether you updated your dependencies in order to 
>> fix a bug or introduce new functionality. I would usually expect additional 
>> code for the latter instance, in which case it’s obviously a minor level 
>> increment.
>
>
> See FAQ on https://semver.org/
>
> Secondly adding return types, this cannot be done in a BC compatible way 
> as having a wider (i.e contravarient) return type breaks LSP.
> However, I would argue that with the imminent release of PHP 7.4 this is a 
> non-issue.
> Indeed PHP 7.4 comes with the feature of contravarient parameter types 
> (i.e type widening) and covarient return types (i.e limiting the return 
> type).
> This means that a library will be able to add return types even though the 
> PSR interface doesn't specify a return type if it decides to only support 
> PHP 7.4 as a minimum version, which IMHO is bound to happen as there are a 
> ton of features bundled with this release of PHP.
>
> I hope that everyone can agree that adding parameter types in a minor 
> version of the PSR spec and leaving return types alone is a better plan 
> than, IMHO, the various other proposals which seem unnecessary complicated.
>
> Best regards
>
> George Peter Banyard
>
>  
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/40acb6f0-2ac8-472d-aa33-d9048e026c70%40googlegroups.com.

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

[Alessandro Lai]

Hi Alexandru,
to be completely truthful, your case shouldn't be an issue for us, because 
we're starting from the assumpion that that implementation follows the PSR, 
which also describe (at the very least with PHPDoc) what types are allowed. 
If the implementation allows other types (on top of the requested ones), 
it's not our concern, per Liskov Substitution principle.

The major is requested to the end users only when adding the argument types 
which, since it's narrowing it's accepted types, is a BC due to the same 
principle.

Il giorno lunedì 7 ottobre 2019 13:22:26 UTC+2, Alexandru Pătrănescu ha 
scritto:
>
> Hi George, Alessandro,
>
> I had this idea that this could be a minor version as well: 
> https://twitter.com/drealecs/status/1180258126215430150 but few minutes 
> later realized that it's not going to work everywhere without BC break on 
> the client side.
>
> If an interface was designed to accept a specific parameter type TypeA 
> but, being defined without a parameter type declaration, the implementation 
> could maybe allowed it to accept other types there: TypeB.
> A client would be able in the current version to call the 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
>
> On Mon, Oct 7, 2019 at 11:10 AM Alessandro Lai  
> wrote:
>
>> 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 the second step (with return types) is IMHO the good step 
>> forward then, because it would push the standard forward, accompanying any 
>> library that would add return types, maybe thanks to PHP 7.4 too.
>>
>> Il giorno sabato 5 ottobre 2019 15:21:47 UTC+2, G. P. B. ha scritto:
>>>
>>> Greetings PHP-FIG,
>>>
>>>
>>> From my understanding this project is to add parameter and return types 
>>> to some of the interfaces defined in PSRs before those exists in PHP.
>>>
>>>
>>> First, adding parameter types is the easiest and also, in my mind, the 
>>> most important type information to add, as it is impossible to add a more 
>>> specific type from a mixed type as it goes against LSP.
>>> This is easy to add as it doesn't break compatibility with current 
>>> implementations, as parameter types can be widened. 
>>> Adding parameter types can be tagged as a version 1.1.0 because semver 
>>> allows to upgrade dependencies in minor version. i.e. updating the PHP 
>>> version is a dependency update.
>>>
>>> Determining whether the change is a patch level or minor level 
>>>> modification depends on whether you updated your dependencies in order to 
>>>> fix a bug or introduce new functionality. I would usually expect 
>>>> additional 
>>>> code for the latter instance, in which case it’s obviously a minor level 
>>>> increment.
>>>
>>>
>>> See FAQ on https://semver.org/
>>>
>>> Secondly adding return types, this cannot be done in a BC compatible way 
>>> as having a wider (i.e contravarient) return type breaks LSP.
>>> However, I would argue that with the imminent release of PHP 7.4 this is 
>>> a non-issue.
>>> Indeed PHP 7.4 comes with the feature of contravarient parameter types 
>>> (i.e type widening) and covarient return types (i.e limiting the return 
>>> type).
>>> This means that a library will be able to add return types even though 
>>> the PSR interface doesn't specify a return type if it decides to only 
>>> support PHP 7.4 as a minimum version, which IMHO is bound to happen as 
>>> there are a ton of features bundled with this release of PHP.
>>>
>>> I hope that everyone can agree that adding parameter types in a minor 
>>> version of the PSR spec and leaving return types alone is a better plan 
>>> than, IMHO, the various other proposals which seem unnecessary complicated.
>>>
>>> Best regards
>>>
>>> George Peter Banyard
>>>
>>>  
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and sto

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

[Alessandro Lai]

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 
way to split that up in any way. That's bad.

In the meantime, with Larry's help, we condensed the proposal in a blog 
post that we just published, followed by a poll to get some feedback; 
please read and give us your opinion: 
https://www.php-fig.org/blog/2019/10/upgrading-psr-interfaces/

Il giorno giovedì 19 settembre 2019 21:23:58 UTC+2, Adrien Crivelli ha 
scritto:
>
>
> On Thursday, 19 September 2019 00:27:09 UTC-7, Alexandru Pătrănescu wrote:
>>
>> we would want to allow upgrading major version of slim without upgrading 
>> to a major version of guzzle.
>>
>
> You assume that this is a requirement, to be able to upgrade major version 
> independently. I am saying that this is not a requirement, and it should 
> not be.
>
> The exact same problem of being forced to wait for both libs to be 
> upgraded before you can upgrade your own project already exists today in 
> composer ecosystem. And it is already solved simply by having a little bit 
> of patience and/or contributing to libs to upgrade them. I really don't see 
> why PSR should have a special status and be managed differently than the 
> entire composer ecosystem.
>

-- 
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 visit 
https://groups.google.com/d/msgid/php-fig/675f1982-3f17-4a73-96f2-4bfb84df679f%40googlegroups.com.