Re: [WG][VOTE] PSR-17 Review

[Glenn Eggleton]

+1

On Tuesday, May 15, 2018 at 12:06:02 PM UTC-4, Matthew Weier O'Phinney 
wrote:
>
> Woody has delegated to me to open a vote to enter the REVIEW period for 
> PSR-17. This vote is open only to PSR-17 Working Group members; at this 
> time, that means: 
>
> - Woody Gilk (Editor) 
> - myself (Sponsor) 
> - Stefano Torresi 
> - Matthieu Napoli 
> - Korvin Szanto 
> - Glenn Eggleton 
> - Oscar Otero 
> - Tobias Nyholm 
>
> The by-laws do not stipulate a time-frame for how long the vote must 
> run, though 2 weeks is the standard period. As such, the vote will run 
> until 23:59:59 on 29 May 2018, or until all members have responded. Once 
> the vote is closed, I 
> will post the results, and indicate next steps for the proposal. 
>
> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS 
> LISTED ABOVE. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@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/d1359ef6-ef6d-4a80-b221-8bca57c3345b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [WG][VOTE] PSR-15 Review

[Glenn Eggleton]

+0

On Thursday, November 30, 2017 at 11:39:19 AM UTC-5, Matthew Weier 
O'Phinney wrote:
>
> At this time, I'm opening a vote to enter the REVIEW period for 
> PSR-15. This vote is open only to PSR-15 Working Group members, which 
> include: 
>
> - Woody Gilk (Editor) 
> - Matthew Weier O'Phinney (Sponsor) 
> - Stefano Torresi 
> - Matthieu Napoli 
> - Korvin Szanto 
> - Glenn Eggleton 
> - Oscar Otero 
>
> The by-laws do not stipulate a time-frame for how long the vote must 
> run. As such, I will set a maximum time-frame of 1 week, and close it 
> sooner if all voters respond before then. Once the vote is closed, I 
> will post the results, and indicate next steps for the proposal. 
>
> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS 
> LISTED ABOVE. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@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/cfe45393-8ff8-4b8c-9952-b5b6f77861b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals] [FIG 3.0 Transition] Core Committee Nominations Open

[Glenn Eggleton]

Hi Adam,

It looks like it's power creep from FIG 3.0.

https://github.com/php-fig/fig-standards/pull/752/files#diff-7aeee0a55f5e81ea8a0b5f9dc76c6822R19

Cheers

On Saturday, November 5, 2016 at 8:45:49 AM UTC-4, Adam Culp wrote:
>
> Sorry, and I hope I'm not beating a dead horse, but when did the 
> Secretaries gain power to nominate? This would indicate they are no longer 
> overseeing the process, but are part of the process. Do they now get to 
> vote as well?
>
> Seriously not trying to cause trouble, just looking for clarity.
>
> Regards,
> Adam Culp
>
> On Thursday, November 3, 2016 at 1:47:04 PM UTC-4, Michael Cullum wrote:
>>
>> Just a few of clarifications:
>>
>> - You can nominate multiple people, in fact, this is to be encouraged so 
>> we have a good number of CC candidates (15-20).
>> - You can nominate yourself if you are a project representative (if you 
>> wish)
>> - Only project representatives and Secretaries can nominate people
>>
>> Most importantly:
>> - If you would like to be on the CC but don't know someone to nominate 
>> you then please send an email to the mailing list or approach a secretary. 
>> The point of nominations is not to exclude people who would be capable of 
>> doing the job just because you aren't friends with any FIG members.
>>
>> --
>> Many thanks
>> The FIG Secretaries
>>
>> On 1 Nov 2016 11:43 p.m., "Michael Cullum"  
>> wrote:
>>
>>> Hi all,
>>>
>>> The nominations for the Core Committee open today. Below are some 
>>> details and FAQs.
>>>
>>> Anyone can be nominated (including Secretaries or project 
>>> representatives but if a Secretary is elected they must then resign as 
>>> Secretary).
>>> Member projects and Secretaries may nominate anyone, or many people, to 
>>> be CC candidates.
>>>
>>> *If you would like to nominate someone*, please get in touch with them 
>>> and speak with them about it first. But please do 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 me, 
>>> Samantha, Amanda (or Larry) to find out a bit about what the role entails. 
>>> You may seek a nomination any way you wish (requesting on the mailing list 
>>> or asking individuals in private).
>>>
>>> *If people could also help spread the word* (via Twitter and the likes) 
>>> about this, so we have a good selection of candidates from different parts 
>>> of the php community, that would be much appreciated.
>>>
>>> A list of nominees will be maintained here 
>>> . Please ensure that you confirm 
>>> your nomination if you wish to and someone nominates you.
>>>
>>> *Nominations close on the 10th November* at 23:59 UTC (Keep in mind DST 
>>> changes).
>>>
>>> *FAQs:*
>>>
>>> *What does the role 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's the timetable?*
>>>
>>>- 1st November: CC Nominations open
>>>- 10th November: CC Nominations close
>>>- 11th November: CC Election voting begins
>>>- 25th November: CC voting ends
>>>- 26th November: CC results announced
>>>- 27th November: CC takes post
>>>
>>> *Election Process Summary*
>>> After nominations close then voting will start. 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, 
>>> this will be clarified when the vote occurs). After which 12 people take 
>>> post. The top four will have terms until August 2018, the next four until 
>>> January 2018, and the final four until May 2017; after 

Re: [PSR-11] Remove ContainerException

[Glenn Eggleton]

I believe removal of it is going to cause a lot of BC Breaks...

For example in Slim we do extend from *ContainerException*

[1]: 
https://github.com/slimphp/Slim/blob/3.x/Slim/Exception/ContainerException.php

We do actually use it.

https://gist.github.com/geggleto/86d039f6f4924b416e6fb1bd1538e269

Cheers

On Monday, August 15, 2016 at 3:10:07 PM UTC-4, Matthieu Napoli wrote:
>
> Hi,
>
> PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get 
> that PSR moving!
>
> Here is a change I would like to suggest: *remove the interface 
> ContainerException*.
>
> After years of using container-interop and ContainerInterface I have not 
> seen a use case for that exception. We initially added it to represent any 
> exception that could happen in a container. But as far I can I see, it's 
> never useful, in other words it could as well be "\Exception" and the 
> result would be the same. Here is the original discussion that lead to such 
> interface: 
> https://github.com/container-interop/container-interop/issues/3#issuecomment-33133155
>
> Here is the pull request to remove the interface: 
> https://github.com/php-fig/container/pull/2
>
> Just to be clear: I am not suggesting to remove NotFoundException, this 
> exception is useful.
>
> If anyone has ever seen a use case for that exception, please let me know 
> :)
>
> Matthieu
>

-- 
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/8be1eb67-6144-4e11-854c-fa3b9e501988%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Glenn Eggleton]

Naming things are hard if and only if their function is hard to define 
I still don't see any added value in turning the $next into a formal 
interface.

Moving on from that: 

NextMiddlewareInterface might be okay for a name...

NextMiddlewareInterface -> process ( Request )


On Sunday, August 14, 2016 at 2:20:22 PM UTC-4, Woody Gilk wrote:
>
> On Sun, Aug 14, 2016 at 12:32 PM, Matthieu Napoli  > wrote: 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
>
> I'm comfortable with this approach. The type hint would still have to 
> be included, though: 
>
> public function process(ServerRequestInterface $request, NextInterface 
> $next) 
> { 
> return $next($request); 
> } 
>
> I also don't love name NextInterface but... naming things is hard. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
>
> > 
> > -- 
> > 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/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr.
>  
>
> > 
> > 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/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Glenn Eggleton]

Hey Phil:
Yep :) That clears it up.

I'm fine with FIG transitioning into a standards body. 

So why don't the members of FIG try and figure out a way to transition it?

I realize FIG 3.0 is a large part of it... but I don't think 3.0 covers 
enough to be called a "Standards Body".

I guess this would likely be the focus of the new secretaries.


On Tuesday, August 9, 2016 at 5:41:47 PM UTC-4, Phil Sturgeon wrote:
>
>
>
> On Tuesday, August 9, 2016 at 4:17:04 PM UTC-4, Glenn Eggleton wrote:
>>
>> If FIG is the standards body why has the FIG not formally changed it's 
>> name?
>>
>
> Sorry for double, but let me take this one!
>
> Glenn: The FIG is not currently a standards body, but the goals of FIG 3.0 
> is moving to become one. Seeing as it is becoming a new thing, Joe is 
> suggesting a name change to reflect that, along with the structural changes 
> + mission statement changes.
>
> Does that clear it up?
>

-- 
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/df11720d-432d-448e-b70b-f275b65a5ac6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Glenn Eggleton]

If FIG is the standards body why has the FIG not formally changed it's name?

On Tuesday, August 9, 2016 at 12:54:04 PM UTC-4, Larry Garfield wrote:
>
> Given that there's ~9 specs being worked on currently in various stages, 
> the idea that FIG's work is "done" seems completely unsupportable. 
>
> FIG is already the de facto PHP Standards Body.  That much is very 
> clear; some here don't want to admit that, but that's very clear from 
> the Reddit thread on the subject, talks at conferences, impacts on 
> projects and tooling (PSR-2 preset in PHPStorm?) and general zeitgeist. 
>
> As Michael noted previously, if a "new" body were to form one of two 
> things would happen: 
>
> 1) FIG would continue, there'd be 2 competing standards bodies, and thus 
> no actual standards.  This is the worst possible outcome for 
> interoperability and collaboration. 
>
> 2) FIG would die off, either quickly or slowly, and the new group would 
> try to fill its ecological niche.  That would be a very messy and 
> complicated process with an ugly, confusing transition period, which 
> benefits no one.  The only way to minimize that would be for FIG to 
> actively shut itself down completely as soon as the new group is setup, 
> and publicly say "they're replacing us, kthxbye".  Which... would have 
> the same net effect as FIG just evolving, but would be more logistically 
> complicated and confuse a bunch of people needlessly. 
>
> FIG isn't "done".  It's not "dead."  It's just evolving.  That's OK.   
> Really!  We should be accustomed to this by now.  PHP as a language and 
> community is one of the fastest evolving around.  PHP has reinvented 
> itself in the last 6-7 years, and FIG has been a part of that.  That's 
> something we should be proud of. 
>
> But FIG can and should evolve along with PHP.  We've done it before.   
> The FIG of 2009 is not at all what we are today.  When the entirely 
> cowboy-free-for-all way of working on specs broke down, we changed the 
> process and added more formality.  (FIG 2.0, which added the formal 
> Editor, Sponsor, and Coordinator.)  It was an improvement.  Now, we're 
> still growing and see a need to evolve our structure further.  That 
> doesn't mean FIG is "done", just that we're evolving to improve 
> ourselves.  In a few years, might the situation have changed further and 
> we need to tack again, with a FIG 4?  Quite possibly!  And when that 
> time comes we should be prepared to evolve with it. 
>
> We, as a community and as FIG, should be looking forwards, how we can 
> continue to help PHP into the future.  Not closing up shop because 
> "whelp, autoloading and coding standards are done, peace out." 
>
> Closing up shop or turning into just a passive rubber-stamp for people 
> we refuse to let collaborate in our space is short-sighted and 
> ultimately self-defeating. 
>
> The fact that there are 9 groups trying to build additional 
> collaborative standards within FIG should be a sign that people do see 
> value in FIG, and we're nowhere close to "done".  If anything, it's a 
> sign of a potentially bright future for FIG and PHP, if we approach it 
> properly. 
>
> --Larry Garfield 
>
> On 08/09/2016 11:17 AM, Joe Ferguson wrote: 
> > By “standards for the language” I mean an official (or as close to 
> official as it can get)  Standards for the PHP language. PHP has never (as 
> far as I’m aware) had a Standards Body. FIG is as close as we’ve come. My 
> observation is that FIG 3.0 should skip FIG and become that standards body. 
> > 
> >> On Aug 9, 2016, at 11:10, Alessandro Pellizzari  > wrote: 
> >> 
> >> On 09/08/2016 16:37, Joe Ferguson wrote: 
> >> 
> >>> I would rather see FIG marked complete, and those leaders interested 
> in 
> >>> moving forward start a new PHP Standards Body that would adopt (not 
> >>> claim) the previous PSRs from FIG and begin work on more standards for 
> >>> the language, not frameworks or packages. 
> >> I partly agree with what you say, but what do you mean by "standards 
> for the language"? Could you give some examples? 
> >> 
> >> 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/65213942-a24d-4fa0-bf9e-02a27fd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Glenn Eggleton]

100% agree with Gary and Paul.

*-interop projects are the embodiment of everything the FIG wishes to 
achieve, "Framework INTEROPERABILTY group". 

Can this be done in the purposed "Working Groups of FIG 3.0" ? I do not 
think so.

>From the TLDR of FIG 3.0, context of talking about the Working groups.

> *Doing what:* Actually working on the spec. They also have the main vote 
> on if the spec is ready for approval, essentially the technical sign-off 
> part of the current acceptance vote.

*Who:* Consists of the Editor (Can be anyone just as per the status quo), 
> core committee representative (sponsor) representatives from member 
> projects with relevance and problem space experts


What is lacking from the TLDR is the political wall FIG 3.0 imposes on 
community members.

This is directly from the draft: 
https://github.com/php-fig/fig-standards/pull/752/files#diff-b58538881047f8ede6b65a2ca2e01261R76

> Members of the general public may apply to join the Working Group at any 
> time, subject to the approval of the Editor or Sponsor if, in their 
> judgment, the applicant's experience and perspective would be particularly 
> valuable to the development of the specification.
>

I think making the community generate an *-interop project before even the 
draft PSR is a good thing for a number of reasons:

   1. It forces the community to do all of the hard work [ 
   like negotiating with design decisions, forming alliances ... etc ]
   2. Out of the interop projects; there becomes implementations available, 
   and wide-spread adoption
   3. FIG is simply to formalize the outcome of the Interop process, 
   nothing more.

I find it quite offensive that FIG thinks it has the power to modify 
community lead interop projects. Nothing that doesn't already have an 
implementation should become a PSR.

*A PSR should be a formalization of something the community already has.*

The only way to do that would be to have an interop-group before you submit 
for a PSR.


On Tuesday, August 9, 2016 at 5:44:08 AM UTC-4, GeeH wrote:
>
> I completely agree with Paul here, this is, for me, at least worth 
> investigating. It takes the onus off the FIG organising the minutiae of HOW 
> standards get created but puts the focus on the group to ratify things that 
> are ready to be added as a standard. Container Interop is a great example 
> here, it was self-formed and has got wide adoption and is ready to be 
> ratified as a PSR in my opinion. I'm not convinced that this group needs to 
> worry about who is involved in creating a standard, or how the   proposals 
> get to the point where they can be considered a PSR - it's been proven that 
> self-formed small groups can get that job done.
>
> I appreciate that the role of this group could not be completely "hands 
> off" - for example, if no standard exists for $x, and the group feels that 
> a standard is needed in this area, then it will need to address the problem 
> and encourage a team to tackle this problem. I know people will say "that's 
> exactly what working groups are going to be!" and I can see that, but in 
> all reality, it's not. Working Groups (from my understanding) will be 
> regulated and will need at least $y number of people of which $z are from 
> the group. I would prefer to see the FIG simply maintain a list of things 
> they think need addressing, and encourage teams to look at the problems. 
>
> I believe that moving the focus of the FIG from a problem-solving body to 
> a ratification body will make life easier for everyone, and will solve some 
> of the problems being addressed in the FIG 3.0 proposal.
>
> Gary
>
> On Monday, 8 August 2016 15:57:39 UTC+2, pmjones wrote:
>>
>> 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 

Re: [PSR-15] FrameInterface

[Glenn Eggleton]

+1

On Friday, July 29, 2016 at 10:15:30 AM UTC-4, Matthieu Napoli wrote:
>
> Thanks Woody and Andrew for your answers,
>
> Type safety is a valid point. I'm all for type safety, however in this 
> case I'm not convinced it's worth it since it's just a callable that takes 
> a request and returns a response. It can't be any simpler (except maybe no 
> arguments), and sometimes simplicity can outweigh doing everything by the 
> book.
>
> I think it's worth considering, especially because if you look at existing 
> PSR-7 middlewares (expressive, slim, etc.), they use "callable $next".
>
> We have no idea how convenient it is (or not) to have that FrameInterface, 
> because currently nobody uses that. It's risky to standardize something 
> that nobody uses.
>
> TL/DR: reality trumps theory.
>
> Also I want to say how important the meta document is: it should contain 
> justification for everything that was decided in a PSR.
>
> Le vendredi 29 juillet 2016 15:42:41 UTC+2, Woody Gilk a écrit :
>>
>> On Fri, Jul 29, 2016 at 4:14 AM, Matthieu Napoli  
>> wrote: 
>> > 
>> > - FrameInterface doesn't represent any actual usage or existing 
>> middlewares today 
>> > - FrameInterface is more complex than `callable` 
>>
>>
>> From Anthony's blog post 
>> http://blog.ircmaxell.com/2016/05/all-about-middleware.html : 
>>
>> > The fact that $next parameter is simply a callable also suffers from 
>> the same problem as above. It means that there's no longer any enforcement 
>> or ability to auto-complete or check types. 
>> > 
>> > Instead, $next should be a formal interface which would allow for type 
>> validation. 
>>
>> I agree with his position. Having a formal interface ensures correct 
>> return type declarations in PHP 7. It shifts responsibility from the 
>> user having to know what is expected to be able to have a direct type 
>> hint that ensures accuracy. 
>>
>> I recommend reading the entire article, it covers a lot why PSR-15 
>> looks like it does, and why we need PSR-17. 
>>
>> -- 
>> Woody Gilk 
>> http://about.me/shadowhand 
>>
>

-- 
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/f2ea4caa-2b82-493c-98fc-f149652050ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Glenn Eggleton]

On Friday, July 29, 2016 at 5:41:07 AM UTC-4, Andrew Carter wrote:
>
> Type safety, IDE type hinting.
>
> A callable can be anything, an interface guarantees parameter types and, 
> in PHP 7, return types.
>

This dynamic property is an asset, not a liability, which is why there is 
so much confusion as to why we must now encapsulate everything in a wrapper 
object which I believe makes the code less readable.

 

>
> Interfaces also indicate explicit implementation of the standard - rather 
> than implicit implementation on the basis that the passed parameter could 
> be executed.
>

I agree, but in this case being able to supply various different 
combinations as a callable is an awesomething thing.
 

>
> All other reasons I've forgotten as to why interface type hints are a good 
> thing.
>

-- 
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/ef049534-9dd0-4541-8540-b5302635d37e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internal] [Discussion] Paul M Jones

[Glenn Eggleton]

On Thursday, July 21, 2016 at 7:46:49 AM UTC-4, Anthony Ferrara wrote:
>
> All,
>
> * Paul continues to provide his excellent (and observable) technical skills
>>
>
> This has been mentioned over and over again; how Paul has unbelievable 
> technical skills. May I point out that he hasn't contributed significantly 
> on a technical basis to any of the proposals since PSR-4... He has filled 
> political support roles (Coordinator, etc), but not technically leading or 
> driving any of the conversations in a non-trivial way.
>
> I'm not saying he doesn't have value to add, but a lot of commentary here 
> seems to be under a delusion that he is contributing on a technical front 
> way more than actuality. Over the past few years, the contributions have 
> largely been political and process oriented (that doesn't say they aren't 
> valuable, just that the majority were not technical).
>
> I say this, not to discredit or diminish Paul's contributions, but to 
> frame them appropriately based on what many people are claiming. To say 
> that he continues to provide his "excellent and observable technical 
> skills" is a flat misrepresentation of the past several years.
>
> Some of you may take this as an insult, and there's nothing I can do to 
> prevent that. It is not meant in any insulting way, but simply as a 
> statement of fact.
>
> The other fact remains: So far Paul has not engaged in any dialog to try 
> to understand what he could do better. He has not engaged in any dialog 
> that would lead to an non-trivial changes which would affect his behavior 
> and hence the point of this thread. His replies in this very thread have 
> been hostile and aggressive. Clearly there is no resolution that's going to 
> be reached.
>
> So my suggestion: Call the vote and settle this. Don't do an open vote 
> (it's susceptible to retaliation, intimidation and back channel politics). 
> Instead, put together a private mailing list for the vote and have members 
> submit their votes there. Then have 2 non-secretaries (ideally one on 
> either side of the "debate") act as auditors to ensure that the vote is 
> fair (they would agree not to disclose voter information). This is the only 
> way to vote that would be truly fair to everyone (both the voters and Paul 
> himself).
>
> Call the vote, let what happens happen, and be done with it.
>

For the love of my sanity :) Plz.

 

>
> Anthony
>

-- 
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/bf9048c9-beea-4984-8ce2-30c52b842051%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-15] Middleware changes?

[Glenn Eggleton]

Hello all,

I want to try to make a case for some changes on the PSR.

I realize it's been through a few iterations, but as a user of psr-7 
middleware I don't see myself adopting the current 15 and here's why.

1) $frame
I have no idea what $frame represents, I cannot explain it to another 
programmer. It is not required. It is merely some kind of syntax sugar, 
that is unreadable.

Ditching frame would leave the signature like so.
function (RequestInterface $request, callable $next);

2) I very much want double pass.

I want to approach this from a few different angles [I am a middleware 
writer, framework maintainer and a framework user... Love multiple hats]


Let's look at it from a *middleware writer's prespective (likely a bit 
bigger than framework maintainers)*
With Double pass, I get a response, I return a response... very simple. I 
focus on doing some kind of unit of work and that's it.

With Single-Pass:
I have to architect a middleware class structure to utilize Factories to 
generate responses to reduce code duplication... Single-pass... much more 
complicated :-1:


*Framework Maintainer (Smallest Group)*

With double-pass: 
- I generated a Response and a Request from the environment and execute the 
stack and render the final output... 

With Single-Pass: 
- I generate a Request from the environment and execute the stack and 
render the final output... Less work :+1:


*Framework User (Largest group)*

With Double-Pass: 
 - I return a response from my route action... with content or a status 
code. Simple and oddly enough Less work! :+1:

With Single Pass:
 - I have to figure out how to create a response object using the framework 
factory implementation :-1: Using the factory method is duplication because 
you will be using this in every Controller/Action. Even if you abstract 
this away, it's still another method call on every Route Action, instead of 
a single call at the framework level. This results in DRY violation [I know 
its super minor].
 - I have to render the content and return...

Double pass is great because we can lower the barrier to entry on our 
frameworks. New Programmers can pick up a project like Slim Framework and 
be immediately productive [that's why I love it so much]... If we force our 
users to use some kind of Factories, that raises the barrier to entry and 
raises the minimum knowledge required to be productive and I think that's a 
step backwards.


Finally, I want to emphasize that the double pass choice has been made in 
other communities as well. One that I am familar with is Express.JS in Node 
land, and it makes it easy transitioning from one language to another [I 
have done both php and node work]. [https://expressjs.com/en/4x/api.html] 

I am not on board with breaking a well defined cross-community informal 
standard.

I know MWOP has his reason for suggesting the edits, and I do think that 
they are better. However as a contributor to open source and helper of many 
novices/juniors/hobbyists/wordpressers I believe that the new changes are 
going to cause so many more introductory problems to modern frameworks... 
and to me that is undesirable.

Thank you for your time.
Glenn

-- 
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/d5f4496b-46c0-4b18-801a-a2b4d345e8ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internal] [Discussion] Paul M Jones

[Glenn Eggleton]

Lukas, I do apologize I see now that I had forgotten some facts in your 
original post.

Paul, thank you for the timeline, it is very informative.
While I do feel as if private resolution was attempted, there was not 
sufficient time given to you to change. Instead you were blind-sided by the 
governing body of the list, likely because they a) did not know about your 
conversation with Lukas, and b) did not try to resolve it with you directly.

What this shows is inadequate communication at the highest levels of this 
group, which might be resolved next month when we vote in 2 secretary 
members.

Finally, I feel as if there's progress in this thread, and I thank all of 
you for taking the time.

Cheers,
Glenn

PS. Lukas, please run for secretary. ty.

>
>
>

-- 
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/6616c7ba-cc5a-44cd-93db-3ebfe804dd00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internal] [Discussion] Paul M Jones

[Glenn Eggleton]

On Wednesday, July 6, 2016 at 1:25:40 PM UTC-4, Larry Garfield wrote:

> On 07/05/2016 12:57 PM, Paul Jones wrote: 
> > Dear Voting Representatives, 
>
> *snip* 
>
> > As such, you can see that the complaint appeals to only one portion of 
> "the PHP Community" -- perhaps a portion with which the complainants 
> themselves identify. But there is another substantial portion, maybe as 
> much as half, to whom the complaint does not appeal. This, along with the 
> comments of those who see little-to-nothing objectionable revealed by the 
> evidence raised against me, should give you reason enough to vote *against* 
> my removal. 
>
> *snip* 
>
> > With that, I leave the fate of my status as a Voting Representative in 
> your hands. Regardless of the result, I thank you for your time and 
> attention. 
>
> Paul, while I am glad you finally responded I find your response 
> extremely disappointing. 
>
> Let's take your own numbers at face value: 70-ish people expressing an 
> opinion, split roughly half and half on whether your behavior is 
> problematic and detrimental to FIG. 
>
> Your response to that is to say "well, only 50% of people hate me and 
> they're probably all of a kind, so you shouldn't vote for my removal." 
>

Can you elaborate on this. Not once did I see that in his post. I believe 
this might be what you are interpreting and not actually what was said.
What I saw was Paul reiterating what he believes are the facts presented 
against him and some really bad napkin math.
 

>
> That is, in fewer words, the entire thrust of your post. 
>
> Several of the people that have spoken out that your behavior is 
> problematic have said they do *not* want you kicked out for it, they 
> want the problem addressed.  That is something that cannot happen 
> without your involvement.  The *only* possible resolutions that do not 
> involve you are "do nothing" or "throw the bum out".  By refusing to 
> engage at all, those are the only possible ways this can end. 
>
> Let me reiterate: Even taking your own "numbers" at face value (and a 
> numbers game is a horrible way to deal with social problems), where you 
> argue "only half of people hate me, so do nothing", I see "Yeesh, half 
> of those involved think Paul is a problem". 
>
> Yet you do not even acknowledge or recognize their complaint.  Not once 
> in your post did you indicate even recognition that there may actually 
> be an issue; instead, you reduce the entire problem to "us vs. them, 
> 50/50 let the ban battle sort it out".  


> If 50% of your colleagues think there's a problem with your behavior, it 
> is an act of extreme hubris to not even entertain the possibility that, 
> just maybe, there's something to it. 


> For the sake of those who have said they do NOT want you kicked out but 
> still want the situation addressed, can you address the actual issue in 
> the slightest?  Can you, as Angie suggested, demonstrate any level of 
> self-awareness or self-reflection?  Do you have any interest in working 
> WITH people who don't want you removed? 
>

As far as I am aware even despite all of this Paul still wants to actively 
contribute to FIG, I believe is a sponsor or coordinator of the Middleware 
PSR.
 

>
> Or are you content to ignore and dismiss the dozen+ people who have said 
> they have a problem with your behavior but don't want you removed over it? 
>
>
The holier-than-thou, "your concerns are beneath me" attitude you're 
> taking here is exactly what people have a problem with. 
>
> --Larry Garfield 
>

I simply do not see the same thing as you in Paul's post, I hope that's 
okay.
I do believe that some or most of us have been biased about this from the 
start.

FWIW from an fig-outsider;

I think a large part of this could have been handled internally among the 
leadership of the FIG group [what I would assume is the secretaries]. I 
don't know the by-laws of the fig.
Posting content like this in publish created a drama level over 9000 and is 
unwarranted until Paul refused to engage with the leadership of the FIG 
Group [ I am only assuming that this part did not happen. ] 
I still assign blame to the secretaries on the incorrect handling of this 
issue. Any good manager [in my opinion] never scolds in front of the them, 
always in private... Or at least that's how I run.

I would love for the secretaries to explain their process and how they came 
to the decision to make these complaints public was made.
I did not see any section as to where they attempted to resolve this 
directly with Paul [I hope that some attempt was made?]

If an attempt was made to reach out to Paul and he ignored it then this 
seems like an adequate escalation step... but otherwise it was a really 
poor choice.

I apologize for making some assumptions, but there has been a lack of 
information about the process of how things were done, and I am really only 
interested in the facts.

The facts as I see it currently:

1) Secretaries have received 

Re: [Internal] [Discussion] Paul M Jones

[Glenn Eggleton]

On Tuesday, July 5, 2016 at 6:53:04 AM UTC-4, Alessandro Lai wrote:
>
> This discussion will not linger indefinitely, there is a two weeks 
> expiration date set up, that is approaching.
> This expiration did not came out of thin air, is the standard pre-vote 
> discussion duration here in the FIG, and Paul himself was very vocal about 
> being strict in this matter, as many have already referenced here in this 
> thread too.
>
> What I found astonishing is that even now, with the expiration so 
> incumbent, we still do not have any word from Paul here, in this 
> discussion. 
> We can't have his side of the argument, we can't know what he thinks about 
> it, despite the fact that he intervened on the matter elsewhere.
>
> If he will not intervene here, not even for a short acknowledgment of the 
> issue, I will find that somewhat disrespectful to the FIG itself and for 
> his position.
>

I can't speak for Paul, but I can say that I wouldn't post in this thread 
if I were him. I don't see any point in him posting in this thread as it 
will simply incite more pitchforks when he attempts to defend himself.

 

>
> Il giorno martedì 5 luglio 2016 09:10:36 UTC+2, Belisar Hoxholli ha 
> scritto:
>>
>> In this discussion it seems like there are no undecided people who can 
>> vote. This is an internal FIG issue as it relates to Paul's membership in 
>> the group. Sure everybody who was interested in the subject, now has an 
>> overview of this. Someone from FIG needs to step in and just put an end to 
>> this process and avoid having this linger indefinitely. 
>>
>> I am pretty sure FIG would benefit more by improving the feedback cycle 
>> for the PSR-s so that members actually get more involved in those 
>> discussions, than focusing on discussions like this. On the broader view, 
>> yes, this discussion needs to happen. It happened.
>>
>> I don't know Paul personally. Most of us however probably might have had 
>> an exchange or two over other mediums, which thanks to filtering and 
>> blocking mechanisms I can safely block. The general impression that was 
>> given to me was that Paul had the attitude that you rather agree with him 
>> or you are stupid, which is why I tend to avoid any exchange whatsoever 
>> because it is just time wasted.
>>
>> Sure, everyone can argue that diversity in opinions is needed for a 
>> structure like FIG to work properly. However, this should be diversity in 
>> opinions as it relates to how members approach the language and code in 
>> general and not diversity in approach to having healthy communities and 
>> being respectful to people. Being disrespectful and inconsiderate is not 
>> cool, is not a "voice that needs hearing", it is just plain wrong. Everyone 
>> likes a rebel, but nobody really cares about a rebel without a cause. 
>> Chronic negativity is detrimental to teams. It directly affects other 
>> members will to contribute. 
>>
>> Many of us love the work FIG does. Many benefit from its work without 
>> even knowing FIG at all. Many of us will encounter FIG members and create 
>> an opinion based on those exchanges. It would be great if that opinion was 
>> one that encourages contribution and taking an taking a more active role in 
>> the community.
>>
>> To those who come here now and say that FIG is more about drama and 
>> internal conflicts, I would like to say that there are plenty of threads 
>> you can contribute on here where PSR's and ideas are discussed, but this is 
>> the one you chose to.
>>
>> I would also like FIG to bring this a conclusion and direct it's focus on 
>> how to improve the feedback cycle and bring in ever more contributions to 
>> the process and finding a long term solution for a striving, healthy 
>> community after this discussion comes to an end.
>>
>>
>> On Thursday, June 23, 2016 at 9:53:03 PM UTC+2, Michael Cullum wrote:
>>>
>>> Hi all,
>>>
>>> Over the past 8 weeks, we [the secretaries] have had a number of voting 
>>> members, former project representatives and well known community members 
>>> alike approach us regarding a situation they believe is being detrimental 
>>> to the continued success of the FIG and the harmony in the group. It is, 
>>> essentially, the impact of Paul M Jones on the harmony of the mailing list 
>>> and the impact his contribution is having on making this group welcoming or 
>>> pleasant to be involved with.
>>>
>>> To avoid putting words in mouths but still convey the common grievances, 
>>> we’ll quote from those who have complained:
>>>
>>>- 
>>>
>>>“This individual is toxic to the group and is therefore directly 
>>>affecting the ability of the group to perform its aims”
>>>- 
>>>
>>>“I believe this individual is the sole biggest cause of loss of 
>>>respect and members for the FIG”
>>>- 
>>>
>>>“I stepped down as a voting representative due to this member”
>>>- 
>>>
>>>“The presence of this individual makes me not want to