Re: New TemplateRendererInterface Proposal

[Matthew Weier O'Phinney]

ecific-extended
> without breaking anything if we define a few base ones.
>
> There's probably somewhere that would break, but the biggest blocker is,
> as noted, getting existing engines on board with this.  If we can do that,
> we have options.  If not, there's nothing to do.
>

Having worked with PSR-14 a fair bit, I _do_ like this approach. Mapping a
_type_ to a _template_ is relatively easy, and allows for both a variety of
approaches as well as things like extension and decoration. I disagree with
having named arguments to determine format; I think that information can be
baked into the view model. One way to do this effectively would be to
decorate a view model into a generic one representing the content type to
generate, and then allow the renderer to compose strategies based on that:

final class RssViewModel
{
public function __construct(public object $decoratedModel) {}
}

The renderer sees the RssViewModel, and passes it to a strategy that knows
how to render an RSS feed, which in turn pulls the $decoratedModel to get
the data to use in the feed. This would allow having helpers like the
following in your handlers:

private function decorateViewModel(ServerRequestInterface $request,
object $viewModel): object
{
return match ($request->getHeaderLine('Accept')) {
'text/html' => new HtmlViewModel($viewModel),
'text/xml' => new RssViewModel($viewModel),
'application/json' => new JsonViewModel($viewModel),
default => new HtmlViewModel($viewModel),
};

Allowing you to then:


$response->getBody()->write($renderer->render($this->decorateViewModel($viewModel)));

(Clearly, you'd use something like willdurand/negotiation for the actual
matching, but you get the gist).

The view model approach has another benefit: you can't forget _required_
data when you render. I can't tell you how many times I've discovered that
the reason a page is broken is because of a mistyped array key, or just
plain missing keys. Having actual typed view models helps developers ensure
that they are providing all the information necessary to render a template.

I don't think we necessarily need to worry about having buy-in from the
various template engines, either. The nice part about this is that all of
this work — mapping view models to templates, calling the engine with the
appropriate data — can all happen in _third-party libraries_ that
_implement_ the FIG standard, but _proxy_ to the underlying engine. Those
implementations can handle how to pass data from the model to the engine,
or even have their own conventions that then _work with_ the engine. (As
examples, they could pull data from any public properties of the view
model; or they could pass the view model as a "model" or "view" template
variable; or the renderer could make use of JsonSerializable or a
`__toString()` method;  or the view model could be bound as "$this" in the
template; etc. Application developers would choose the implementation that
suits their application and/or development needs.)

This approach sidesteps the whole "template composes its renderer". View
models can compose other services if they want, but the point is that they
do not contain the information needed to render themselves; that's up to
the renderer.

On top of that, it bypasses the whole "create a spec for referencing
templates", which is very difficult to test, harder to enforce, and likely
leaky (talking from experience here!).

So, I'll toss my hat in the "go with a view model" ring. I think the
following is as simple as it gets and as flexible as it gets:

interface Renderer
{
public function render(object $viewModel): string
}

Now, going back a few emails, there was discussion about returning the
rendered string, vs _streaming_.

I think it's interesting... but streamed content is _very_ rare in PHP, and
very convoluted to achieve. When using PSR-15 and PSR-7, I'd argue that
might become the realm of a specialized StreamInterface implementation. But
if we were to deal with it in this proposal, I'd argue for a `stream(object
$viewModel): void` or `stream(StreamInterface $stream, object $viewModel):
void` method, vs the proposed render/capture, as it would make it more
clear the _context_  for rendering (a stream).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWC_L0-rjf822c%3D0idU2UOdAWGgiQ_FBnZQ%3DHRzw0xwug%40mail.gmail.com.

Re: [VOTE][CC] Expulsion Vote for Stormpath PHP SDK

[Matthew Weier O'Phinney]

+1

Thanks for your efforts in trying to contact project reps!

On Thu, Oct 5, 2023, 9:38 AM Vincent de Lau  wrote:

> This thread is to collect Core Committee votes on the Stormpath PHP SDK
> Expulsion vote.
>
> The proposal is to expel Stormpath PHP SDK as a Member Project.
>
> There have been various efforts to prevent this drastic measure, without
> any result. The final discussion thread with the background leading to this
> proposal can be found here:
> https://groups.google.com/g/php-fig/c/zYvUOTH-y3I
>
> Voting ends by 2023-10-19 17:00 UTC
>
> Voting options:  For (+1), Against (-1), or Abstain (+0)
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#expulsion-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/7d95e151-c1ab-42a1-a0bc-177f2b1f0438n%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/CAJp_myVGLZEnufsfBVy5xJx-RNKAwahWC4Z4OqjF0FLkLTnudg%40mail.gmail.com.

Re: [VOTE][CC] Expulsion Vote for eZ Systems

[Matthew Weier O'Phinney]

Much as I hate to, +1

On Thu, Oct 5, 2023, 9:37 AM Vincent de Lau  wrote:

> This thread is to collect Core Committee votes on the eZ Systems Expulsion
> vote.
>
> The proposal is to expel eZ Systems as a Member Project.
>
> There have been various efforts to prevent this drastic measure, without
> any result. The final discussion thread with the background leading to this
> proposal can be found here:
> https://groups.google.com/g/php-fig/c/zYvUOTH-y3I
>
> Voting ends by 2023-10-19 17:00 UTC
>
> Voting options:  For (+1), Against (-1), or Abstain (+0)
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#expulsion-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/f1b409b7-0463-4b67-b840-99ab90011b61n%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/CAJp_myXmj7Cto1nVot0TcgRGzF8H95p6uTGc5QjXZ68SVukaOg%40mail.gmail.com.

Re: [VOTE][CC] Hyperf Membership vote

[Matthew Weier O'Phinney]

+1

On Mon, Jul 24, 2023, 4:14 AM Vincent de Lau  wrote:

> This thread is to collect Core Committee votes on the Hyperf Membership
> vote.
>
> The proposal is to accept Hyperf as a Member Project. Hyperf will be
> represented by Leo Cavalcante. The membership application is being
> sponsored by Vincent de Lau as a Core Committee member.
>
> The membership application and discussion thread can be found here:
> https://groups.google.com/g/php-fig/c/zwsMt9E6wzw
>
> Voting ends by 2023-08-07 10:00 UTC
>
> Voting options:  For (+1), Against (-1), or Abstain (+0)
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/6e06dcbc-e9af-4f65-a59a-a29e20451eb4n%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/CAJp_myWwu6m%2BZFGkNuTpHRZi7Rcs_U2DPM%2BjsMQJ9s%3DDow_85w%40mail.gmail.com.

Re: [VOTE][CC] Copyright Ownership Approval Vote

[Matthew Weier O'Phinney]

+1

On Fri, Jul 14, 2023, 11:25 AM Mark Niebergall 
wrote:

> Hi Everyone,
>
> I'm calling a CC vote for the approval of the Copyright Ownership updates.
> This change adds a "Copyright Ownership" section to the Licensing Policies
> section (https://www.php-fig.org/bylaws/licensing-policies/). The
> associated PR is: https://github.com/php-fig/fig-standards/pull/1290
>
> Approval Voting rules apply (
> https://www.php-fig.org/bylaws/voting-protocol/#vote-types):
>
>- Only Core Committee members may vote, either For (+1), Against (-1),
>or Abstain (+0). Quorum is 50%. A 2/3 majority is required for passage.
>
> Voting will be open for two weeks (until 2023-07-28 16:30:00 UTC) or until
> all quorum members have voted, whichever occurs first. If the vote passes,
> the PR will be merged and the Licensing Policies will be updated on the
> website.
>
> - Mark Niebergall
>
> --
> 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/bac05ee7-803a-444d-949f-43443a6e0b51n%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/CAJp_myXkazMUDy%3DmNgCgPq66bJ9XwGM-oOGWyDwUU5ddYW6MgA%40mail.gmail.com.

Re: [VOTE][CC][PSR-7] Errata proposal, urlencoding clarification

[Matthew Weier O'Phinney]

+1 from me

On Wed, Jun 14, 2023, 9:01 AM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> In https://github.com/php-fig/fig-standards/pull/1298, David Buchmann
> proposed errata regarding expectations around URL encoding behavior of the
> authority segment, as well as expectations to prevent double encoding. The
> discussion period resulted in a few verbiage changes to improve clarity.
>
> As such, I am now initiating the vote. This vote is for core committee
> members only. CC members, please vote in the thread following. The vote
> will be complete two weeks from today.
>
> --
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myVYYUf73KyCPgq__3wt7Mj2Ww2NsLacn%2B32TpOshvYjQg%40mail.gmail.com.

[VOTE][CC][PSR-7] Errata proposal, urlencoding clarification

[Matthew Weier O'Phinney]

In https://github.com/php-fig/fig-standards/pull/1298, David Buchmann
proposed errata regarding expectations around URL encoding behavior of the
authority segment, as well as expectations to prevent double encoding. The
discussion period resulted in a few verbiage changes to improve clarity.

As such, I am now initiating the vote. This vote is for core committee
members only. CC members, please vote in the thread following. The vote
will be complete two weeks from today.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWSBNXgZ%3Dk_ft5NVy%2B2vonTJ4firUn9mwkqe-f8eKbfdA%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

Thanks, Vincent! I accept the nomination!

On Thu, Jun 1, 2023, 7:54 AM Vincent de Lau  wrote:

> I would like to nominate Matthew Weier O'Phinney for another term of CC
> membership. His contribution to the FIG is invaluable and I would like see
> him continue his work.
>
> Kind regards,
> Vincent de Lau
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/9a819330-b705-45d1-8e94-58e935941bcfn%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/9a819330-b705-45d1-8e94-58e935941bcfn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAJp_myWXr5v6dtY-Edirez928Of4fPF8qFaA4BT%2BNW-KUb5dUQ%40mail.gmail.com.

[PSR-7] Errata proposal, urlencoding clarification

[Matthew Weier O'Phinney]

In https://github.com/php-fig/fig-standards/pull/1298, David Buchmann has
proposed errata regarding expectations around URL encoding behavior of the
authority segment, as well as expectations to prevent double encoding.

The proposal is solid and codifies how current implementations are
performing these tasks. I hereby open the mandatory two week discussion
period prior to voting.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myW16C5_cprJP2pzv7%2BHNOK87OF9JKew6WyFTqJA12zEgg%40mail.gmail.com.

Re: [BYLAW] New: funding bylaw

[Matthew Weier O'Phinney]

 TLD
>>>>>> that supports multi-year registrations are registered for the next
>>>>>> five
>>>>>> years or so *and* are yearly topped up by another year. That way
>>>>>> there's
>>>>>> always a 5-year headroom if something goes wrong (e.g. the registrar
>>>>>> going out of business).
>>>>>>
>>>>>> In fact it appears that the current registrar "Namecheap" does
>>>>>> support
>>>>>> multi-year registrations:
>>>>>>
>>>>>> https://www.namecheap.com/support/knowledgebase/article.aspx/770/35/is-it-possible-to-registerrenew-a-domain-name-for-more-than-10-years/
>>>>>>
>>>>>> Best regards
>>>>>> Tim Düsterhus
>>>>>>
>>>>>> --
>>>>>> 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 view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/php-fig/3ab0d950-32f7-75c7-fd19-5e691676f8be%40bastelstu.be
>>>>>> .
>>>>>>
>>>>> --
>>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/24143cea-6a78-4b1e-84b9-a372c84b9a69n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/24143cea-6a78-4b1e-84b9-a372c84b9a69n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Matthew Weier O'Phinney
>> mweiero...@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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/54a06d52-974b-4f12-963c-6cea343d66a1n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/54a06d52-974b-4f12-963c-6cea343d66a1n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUeR6aa24_rpxLGFxy%3DE4n1q828jiVDmuYHE9RY%3DqrmiQ%40mail.gmail.com.

Re: PSR-7 typo in 1.6 Uploaded files

[Matthew Weier O'Phinney]

On Mon, Apr 10, 2023, 3:04 PM Larry Garfield  wrote:

> On Fri, Apr 7, 2023, at 3:37 PM, Jérémie Mossetchafik wrote:
> > Hello, for information there is an issue on the PSR-7 current
> specifications.
> >
> > On line 538 of this file the array key should be 2, not 3. I found out
> > because I implemented a parser for  $_FILES and used the specifications
> > to write the unit tests.
> >
> >
> https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-7-http-message.md?plain=1#LC538
> >
> > I was asked on discord to create an issue or PR but I did not found how
> > I can have the permission to do so.
>
> Typically you'd fork the project on GitHub, make a branch in your own
> fork, make the change, push the branch, and make a PR out of that.
>
> In this case, it's a one character change so it's probably easier to just
> use the "Edit" button on GitHub, which does essentially that behind the
> scenes for you, all from the browser.
>
> No particular permissions are necessary for either approach, other than
> having a GitHub account.
>

Once you've made the PR, please ping me (@weierophinney on GH) to review,
as I'm the editor.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWD682OYQeLw01PqdcsG97cTb06TszOFnXm2D7w3qsyZg%40mail.gmail.com.

Re: [BYLAW] New: funding bylaw

[Matthew Weier O'Phinney]

unsubscribe from this group and stop receiving emails from it, send
>>>> an email to php-fig+u...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/php-fig/3ab0d950-32f7-75c7-fd19-5e691676f8be%40bastelstu.be
>>>> .
>>>>
>>> --
> 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/24143cea-6a78-4b1e-84b9-a372c84b9a69n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/24143cea-6a78-4b1e-84b9-a372c84b9a69n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUgxVQPq%2BF8M9mSLOB4N9tt1qj0fQF_Piyv7X6E2ibgPw%40mail.gmail.com.

Re: [VOTE][CC] Coding Style 2.0.0 Approval Vote

[Matthew Weier O'Phinney]

+1

On Mon, Mar 20, 2023 at 11:05 AM Korvin Szanto 
wrote:

> Hi Everyone,
> The `2.0.0` version of the Coding Style PER has been approved by its
> working group. This update introduces requirements for new PHP syntax
> and offers clarification on existing syntax such as trailing commas,
> empty spaces in function and class bodies, new keywords, named
> arguments, match expressions, short closures, enums, attributes, and
> more.
>
> You can review the full list of changes here:
> https://github.com/php-fig/per-coding-style/compare/1.0.0...0e0fc1d
>
> This is an approval vote limited to the Core Committee. A 50% quorum
> and a 2/3 majority are required for this vote to pass. If successful
> `0e0fc1d` will be tagged as `2.0.0`.
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CANeXGWW7VPwak_u84%3DyTiGW5MywencSrkYqD_M1WOd3gAoM_BA%40mail.gmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWX%2B%2B1q91-hSES-RdOtXTsB9WBNLwd_juhVkUoGK33Pkw%40mail.gmail.com.

Re: [VOTE][PSR-7] Type declaration updates

[Matthew Weier O'Phinney]

+1 from me (obvs!)

On Monday, March 13, 2023 at 3:02:57 PM UTC-5 Matthew Weier O'Phinney wrote:

> As the two week comment period has concluded, I hereby call a vote of the 
> Core Committee to approve the following PRs to update PSR-7 to add explicit 
> type declarations.
>
> This is a Core Committee vote requiring a 50% quorum and 2/3 majority, 
> with voting ending on 30 March 2023.
>
>
>- Version 1.1 patch (parameter type declarations): 
>https://github.com/php-fig/http-message/pull/94
>- Version 2.0 patch (return type declarations): 
>https://github.com/php-fig/http-message/pull/95
>- Specification errata patch: 
>https://github.com/php-fig/fig-standards/pull/1296
>
>

-- 
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/758c478b-147b-475e-b7ee-f32ddcc8508en%40googlegroups.com.

[VOTE][PSR-7] Type declaration updates

[Matthew Weier O'Phinney]

As the two week comment period has concluded, I hereby call a vote of the 
Core Committee to approve the following PRs to update PSR-7 to add explicit 
type declarations.

This is a Core Committee vote requiring a 50% quorum and 2/3 majority, with 
voting ending on 30 March 2023.


   - Version 1.1 patch (parameter type declarations): 
   https://github.com/php-fig/http-message/pull/94
   - Version 2.0 patch (return type declarations): 
   https://github.com/php-fig/http-message/pull/95
   - Specification errata patch: 
   https://github.com/php-fig/fig-standards/pull/1296

-- 
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/d84ebc94-ee4e-4928-aceb-10563b25a163n%40googlegroups.com.

Re: PSR-7 evolution proposal for parameter and return type declarations

[Matthew Weier O'Phinney]

REMINDER: Discussion period ends this coming Monday, March 13, after which
I'll open the vote with the CC.

We've had a few rounds of discussion and a few comments, mostly around the
choice of PHP version constraints. I'm going both simultaneously less
restrictive (allowing PHP 7 versions, as there are LTS versions of PHP in
the ecosystem — some advocated for jumping directly to 8) and more
restrictive (not doing a >= 8 constraint, but instead ^8.0, as
compatibility with a new major is not guaranteed).

Please review the PRs and let me know early if you see anything glaring
that should be changed before voting.

On Mon, Feb 27, 2023 at 1:54 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Hi, all!
>
> This proposal has been a long time coming: formal addition of parameter
> and return type declarations for PSR-7.
>
> I'd like to thank GitHub user @stilch for creating the patches and being
> patient enough to wait almost two years for me to get around to testing,
> reviewing, and creating the proposal.
>
> In sum, this a proposal following our PSR Evolution bylaws (
> https://www.php-fig.org/bylaws/psr-evolution/) to update PSR-7 to:
>
> - Create a version 1.1 of the interfaces that adds parameter type
> declarations (see https://github.com/php-fig/http-message/pull/94)
> - Create a version 2.0 of the interfaces that adds return type
> declarations (see https://github.com/php-fig/http-message/pull/95)
>
> The PSR-7 spec changes can be found here:
> https://github.com/php-fig/fig-standards/pull/1296
>
> I have tested the changes against the PSR-7 integration test suite,
> Diactoros, and a variety of real-world applications. For consumers,
> generally no changes are necessary; applications I had "just worked". For
> implementers, the primary change is that a fair amount of code used to
> validate parameter input can be removed, though in order to comply with the
> spec, they must also ensure that they add return type hints at the minimum
> for a new MAJOR version (this is documented as part of the Evolution
> by-laws anyways). Assuming passage of the specification, Diactoros, at the
> very least, can be updated within a day as I've already got patches
> prepared for new minor and major versions, and the changes result in a net
> removal of code, and fewer errors flagged by Psalm. I consider this a net
> win!
>
> The other ecosystem concern will be PSR-15, PSR-17, and PSR-18. Each of
> these consumes PSR-7, so at the minimum, they will need to release new
> minor versions that allow usage of either ^1.0 or ^2.0 of the
> psr/http-message package. I've already notified Woody Gilk so he can track
> the updates.
>
> At this point, I'm opening a 2 week comment period before calling a vote.
>
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXf0MyBjvgGRzrzPdhLtEo9HnJLYXUve1dhEA2EiCH%3DRA%40mail.gmail.com.

PSR-7 evolution proposal for parameter and return type declarations

[Matthew Weier O'Phinney]

Hi, all!

This proposal has been a long time coming: formal addition of parameter and
return type declarations for PSR-7.

I'd like to thank GitHub user @stilch for creating the patches and being
patient enough to wait almost two years for me to get around to testing,
reviewing, and creating the proposal.

In sum, this a proposal following our PSR Evolution bylaws (
https://www.php-fig.org/bylaws/psr-evolution/) to update PSR-7 to:

- Create a version 1.1 of the interfaces that adds parameter type
declarations (see https://github.com/php-fig/http-message/pull/94)
- Create a version 2.0 of the interfaces that adds return type declarations
(see https://github.com/php-fig/http-message/pull/95)

The PSR-7 spec changes can be found here:
https://github.com/php-fig/fig-standards/pull/1296

I have tested the changes against the PSR-7 integration test suite,
Diactoros, and a variety of real-world applications. For consumers,
generally no changes are necessary; applications I had "just worked". For
implementers, the primary change is that a fair amount of code used to
validate parameter input can be removed, though in order to comply with the
spec, they must also ensure that they add return type hints at the minimum
for a new MAJOR version (this is documented as part of the Evolution
by-laws anyways). Assuming passage of the specification, Diactoros, at the
very least, can be updated within a day as I've already got patches
prepared for new minor and major versions, and the changes result in a net
removal of code, and fewer errors flagged by Psalm. I consider this a net
win!

The other ecosystem concern will be PSR-15, PSR-17, and PSR-18. Each of
these consumes PSR-7, so at the minimum, they will need to release new
minor versions that allow usage of either ^1.0 or ^2.0 of the
psr/http-message package. I've already notified Woody Gilk so he can track
the updates.

At this point, I'm opening a 2 week comment period before calling a vote.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXR9atuO58AKAFcfEVVhZ7KBgJ7jw%2Bcrgpnpu1%3D8TGRZg%40mail.gmail.com.

Re: [ACCEPTANCE VOTE][CC] PSR-20 Clock Interface

[Matthew Weier O'Phinney]

+1


On Thu, Nov 3, 2022, 1:47 PM Chuck Burgess  wrote:

> I am opening an ACCEPTANCE VOTE for PSR-20, the Clock Interface. Per the
> by-laws, the  acceptance vote is limited to Core Committee members. The
> vote will close either at 23:59:59 UTC on 18 November 2022, or when all
> CC members have cast their vote, whichever comes first.
>
> - Specification:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
> 
>
> - Meta document:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md
> 
>
>
> Trial Implementations:
> - https://packagist.org/packages/welearn/clock
> - https://packagist.org/packages/org_heigl/clock
>
> Real-life implementations waiting for PSR-20 to be ready:
> - https://packagist.org/packages/lcobucci/clock
> - https://packagist.org/packages/kreait/clock
> - https://packagist.org/packages/beste/clock
>
> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
> Current CC Members are as follows:
>
> Larry Garfield
> Matthew Weier O’Phinney
> Cees-Jan Kiewiet
> Chris Tankersley
> Korvin Szanto
> Chuck Burgess
> Enrico Zimuel
> Michelle Sanver
> Alessandro Chitolina
> Ken Guest
> Jaap van Otterdijk
> Navarr Barnier
>
>
> Chuck Burgess, Sponsor
>
> --
> 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/CANsgjns_yQx8ma-OK1Jc%3D5Jt9_8eqe7UBeAn%2B0VRKwNX8aj7jg%40mail.gmail.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/CAJp_myUwDjNncmLFnxZZcA3ar7%3DjhOGNJihnbEu-nV7C_-YD8A%40mail.gmail.com.

Re: [VOTE][CC] fig/log-test 1.0.0 Approval Vote

[Matthew Weier O'Phinney]

+1

On Fri, Aug 19, 2022, 1:17 AM Ralf Lang  wrote:

> Hello everyone,
>
>
> I hereby call a CC vote for the approval of the first release 1.0.0 of
> auxiliary resource fig/log-test.
>
> The library is a direct port of existing repo psr/log-util (unreleased)
> which has been in the current form for long but has naming issues. You can
> view it as-is here: https://github.com/php-fig/log-test/ - Direct editing
> was the exception.
> Further evolution will be handled as PRs with the appropriate process.
>
> As per the bylaws I understand this is an Approval vote and it requires
> 2/3 approval/yes of voting CC Members, voting quorum 50%.
>
> Mission and Structure
>
>- Auxiliary Resources (ARs) are additional tools, code libraries, or
>examples that relate to or support a PSR or PER. Examples include common
>partial implementations of a PSR or PER, "no-op" implementations, or
>testing utilities for PSR or PER implementations. All ARs must directly
>relate to one or more PSRs or PERs. An AR is developed by a Maintainer.
>- For changes that would qualify as major releases, the release is
>subject to a mandatory Approval Vote from the Core Committee.
>
> Voting Protocol
>
>- Only Core Committee members may vote, either For (+1), Against (-1),
>or Abstain (+0). Quorum is 50%. A 2/3 majority is required for passage.
>
> Votes take place over a period of two weeks (or at the reaching of 100%
> quorum), so votes will be accepted up to 2022-09-02 11:00:00 UTC.
>
>
> Regards
>
> Ralf Lang
>
> --
> 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/23ffedad-e087-f10c-da66-d7f95c61e26e%40gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWyahH15f1x9xT7FcnnjeC6oQmYNQf024FPHuOF8vSPvQ%40mail.gmail.com.

Re: [VOTE][CC] Coding Style 1.0.0 Approval Vote

[Matthew Weier O'Phinney]

+1

On Wed, May 25, 2022, 11:20 AM Korvin Szanto  wrote:

> Hi Everyone,
> The Coding Style PER 1.0.0 tag has been voted ready by the working group.
> This
> version of the Coding Style PER is effectively the same as PSR-12 with only
> basic updates to terminology, naming, and formatting so any project
> compatible with PSR-12 today will also be compatible with this proposed
> 1.0.0.
> Please review the full list of changes here:
> https://github.com/php-fig/per-coding-style/compare/8201676...b5cac84
>
> This is an approval vote limited to Core Committee members, so quorum is
> 50%
> and 2/3 majority is required to pass. If this vote passes, `b5cac84` will
> be
> tagged as `1.0.0`.
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CANeXGWUR2Q3pv4Vuqce0w3WFO7%3DnfJSm0Hncmi3eaFbs%3DcEKyQ%40mail.gmail.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/CAJp_myXtHWD91as4yiAt%2BwvpPOGRFAKGV3pckP7Uq%2BSth8vpjQ%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

+1

On Thu, May 19, 2022, 11:21 AM Korvin Szanto  wrote:

> Hi Everyone,
> The Coding Style PER is ready for a 1.0.0 tag! This version is effectively
> the
> same as PSR-12 with only basic updates to terminology, naming, and
> formatting.
> You can review the full list of changes here:
> https://github.com/php-fig/per-coding-style/compare/8201676...master
>
> This vote is limited to the members of the working group:
>
> - Editor: Me
> - Sponsor: Chris Tankersley
> - Alexander Makarov
> - Kathryn Reeve
> - Ken Guest
> - Larry Garfield
> - Luke Diggins
> - Woody Gilk
>
> This is a readiness vote so quorum is 50% and 2/3 majority is required to
> pass.
> If this vote passes, another vote will begin for the Core Committee's
> approval.
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CANeXGWVA94Fq3R71J5yP9L8xZjf%2BCgfyxJqd4R8t6KcMONG-4w%40mail.gmail.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/CAJp_myVPWroQK-wJSNU6KJad-O1PvkQ5zSEg-HJaxC0P4a0pTg%40mail.gmail.com.

Re: [Vote] Maintainer for log-util library

[Matthew Weier O'Phinney]

+1 from me.

On Wed, May 18, 2022, 1:36 PM Larry Garfield  wrote:

> I hereby open a Core Committee Vote to appoint Ralf Lang as Maintainer for
> a new log-util library that kinda-sorta exists but has no releases yet. :-)
>
> https://github.com/php-fig/log-util/
>
> This is an Approval Vote, Core Committee only, quorum is 50%, passage is
> 2/3.  The vote will end on 1 June or when all of the CC has voted,
> whichever occurs first.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/f7e8b221-fb23-4894-8dd8-7745d3ee110e%40www.fastmail.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/CAJp_myWMma87AYBDYXJAwtGkmH-1sDhVQ0CV90Hy%2BMtnuDaRag%40mail.gmail.com.

Re: [VOTE][PSR-7] Header validation errata

[Matthew Weier O'Phinney]

Obviously, +1 from me.

On Wed, Apr 20, 2022 at 9:27 AM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Hi, all!
>
> The two week discussion period regarding proposed errata on PSR-7 related
> to validation of header fields has completed. We had some feedback
> basically immediately, and that feedback was incorporated. For reference:
>
> - https://github.com/php-fig/fig-standards/pull/1274
>
> The tl;dr: PSR-7 implementations SHOULD strictly validate header names and
> contents according to the most recent HTTP specification ([RFC 7230#3.2][1]
> at the time of writing). The implementation SHOULD reject invalid values
> and SHOULD NOT make any attempt to automatically correct the provided
> values. The errata provides more specific details about this validation,
> but it's primarily around line wrapping of headers.The changes are
> suggested to ensure that implementations provide a minimum amount of
> security for end-users.
>
> At this time, I am opening a VOTE for inclusion of this errata in PSR-7.
> The vote is open to CC members only, and requires a 50% quorum, and a 2/3
> approval to pass. The vote will end 2 weeks from the time I send this.
>
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXq%3D%2B2hC%2BPQ95zQ9_c7rR%2By5FLT6kgxTVOW%3D%3D-E44vFqQ%40mail.gmail.com.

[VOTE][PSR-7] Header validation errata

[Matthew Weier O'Phinney]

Hi, all!

The two week discussion period regarding proposed errata on PSR-7 related
to validation of header fields has completed. We had some feedback
basically immediately, and that feedback was incorporated. For reference:

- https://github.com/php-fig/fig-standards/pull/1274

The tl;dr: PSR-7 implementations SHOULD strictly validate header names and
contents according to the most recent HTTP specification ([RFC 7230#3.2][1]
at the time of writing). The implementation SHOULD reject invalid values
and SHOULD NOT make any attempt to automatically correct the provided
values. The errata provides more specific details about this validation,
but it's primarily around line wrapping of headers.The changes are
suggested to ensure that implementations provide a minimum amount of
security for end-users.

At this time, I am opening a VOTE for inclusion of this errata in PSR-7.
The vote is open to CC members only, and requires a 50% quorum, and a 2/3
approval to pass. The vote will end 2 weeks from the time I send this.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myVoiiH2qd_HwTxT5UgSeGqNVqmsQ4sDur1Km%2BYuqccigQ%40mail.gmail.com.

[PSR-7] Header validation errata

[Matthew Weier O'Phinney]

Hi, all!

Tim Düsterhus has proposed errata on PSR-7 related to validation of header
fields, based on updates to the HTTP specifications as well as observation
of CVEs related to invalid header fields that are improperly handled:

- https://github.com/php-fig/fig-standards/pull/1274

We've already had a fair amount of feedback on the proposed errata, and it
it looks to be in pretty solid shape.

At this time, as Editor of the spec, I am opening the requisite 2 week
discussion period before calling for a vote.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWx0N0_QS5VBVPQ3Y6Hg65baWwkYKM0CyLz2HUskC6D9A%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] Tracing PSR

[Matthew Weier O'Phinney]

+1 from me

On Tue, Mar 29, 2022 at 3:03 AM Alessandro Chitolina 
wrote:

> As the Sponsor for this candidate PSR, after seeing a positive response
> and a great interest from the community, I hereby call the Entrance Vote.
>
> The PR of this proposal is here:
> https://github.com/php-fig/fig-standards/pull/1273
>
> Editor: Adam Allport
> Sponsor: Alessandro Chitolina
> Working Group Members
> Alex Bouma
> Ben Edmunds
> Brett McBride
> Timo Michna
>
> Please do not reply to this topic if you are not a CC member.
>
> --
> 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/46b2a157-b19f-4f98-842c-a85ae2707437n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/46b2a157-b19f-4f98-842c-a85ae2707437n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWWiZdjBPYVU%2B8b1OR%3DSkJjYz-admPsd7nd3sY-LBC2GQ%40mail.gmail.com.

Re: [VOTE] Core Committee Election January 2022

[Matthew Weier O'Phinney]

Voting as the Laminas representative:

1. Enrico Zimuel
2. Ken Guest
3. Chris Tankersley
4. Korvin Szanto
5. Florian Engelhardt
6. Navarr Barnier


On Sat, Jan 15, 2022 at 10:51 AM Vincent de Lau  wrote:

> Hello everyone,
>
> Yesterday the nomination period ended, and we got 7 nominations in total,
> which is great!
> For the secretary seat, we have one uncontested nomination. For the Core
> Committee, we have 6 nominations against 4 available seats, so this means
> that we will be holding a proper election, starting now! The nominees are
> (in temporal order of nomination):
>
>- Korvin Szanto - https://groups.google.com/g/php-fig/c/Rv43KRFOt_A
>- Navarr Barnier - https://groups.google.com/g/php-fig/c/kAOTuIFB7Eg
>- Chris Tankersley - https://groups.google.com/g/php-fig/c/xtrwd7o6SOQ
>- Ken Guest - https://groups.google.com/g/php-fig/c/QtKqPOYZ2HA
>- Florian Engelhardt -
>https://groups.google.com/g/php-fig/c/wjxZf1VMzDA
>- Enrico Zimuel - https://groups.google.com/g/php-fig/c/vA-dFT8lXbM
>
> You can find information about the nominees inside the linked nomination
> thread. 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, the vote for CC members is open to
> Project Representatives and individuals from the community. To be eligible
> to vote as an individual, the bylaw established the following threshold:: 
> *"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."* We will obviously consider Discord in this
> account; feel free to reach to me or any other secretary to check on the
> matter. *When can you vote?* Voting will be open in this thread until
> January 29th 17:00 UTC.
> *How to vote*
> Votes are cast by replying in this thread on the list. For individuals
> that have not used the mailing list before, please be sure to identify
> yourself, for instance by including your Discord or Github handle.
> 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 all 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, secretaries will be announcing the results, and all
> the newly elected (both CC members and secretary). Thanks, and happy
> voting! Alessandro Lai and Vincent de Lau 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/22dd11d5-8d4a-46d7-ab77-e291b4e03f49n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/22dd11d5-8d4a-46d7-ab77-e291b4e03f49n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWkHHrRKyeKD0U%3DGgTCdg7%3D4%3Dp%2BMyJjg2%3DVzOBPup8Yvg%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] PER Coding Style

[Matthew Weier O'Phinney]

+1

On Sat, Jan 15, 2022 at 9:33 PM Chris Tankersley 
wrote:

> As the sponsor for this PER Working Group, I hereby call an entrance vote
> for the PER Coding Style.
>
> The purpose of this PER is to migrate PSR-12 to a living document under
> the new PHP Evolving Recommendations structure. This will allow the coding
> style recommendations to more quickly integrate new syntax features
> provided by the language.
>
> The PER will be worked on here:
> https://github.com/php-fig/per-coding-style
>
> This is a Core Committee vote only.
>
> Editor: Alexander Makarov
> Sponsor: Chris Tankersley
> Working Group:
> - Ken Guest
> - Larry Garfield
> - Korvin Szanto
> - Woody Gilk
>
> We have a few others interested that may join the WG later.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAL9n4XMhazaQfZxfpuTrSM%3Dy2XcmE5kFD9nXZkgqK9_EuLF3sA%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAL9n4XMhazaQfZxfpuTrSM%3Dy2XcmE5kFD9nXZkgqK9_EuLF3sA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWRriyBUtdqyEgHdRiNKJyC3ZU4yOak0EKzi4ekNjQLqw%40mail.gmail.com.

[Nomination][CC] Enrico Zimuel

[Matthew Weier O'Phinney]

I hereby re-nominate Enrico Zimuel for a position on the Core Committee.

Enrico is a security and cryptography expert, and a long-time open source
maintainer. I had the wonderful privilege of working with him for quite
some years on Zend Framework, and he now is the lead developer for the
ElasticSearch PHP SDK. Moreover, he's an excellent communicator, and
skilled architect.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myV7g%2BQrh_YAr4973HqZh6CoVpZ7Lx7vVFhd8rJ1JiMEXw%40mail.gmail.com.

Re: [Entrance Vote]{CC] Localization PSR

[Matthew Weier O'Phinney]

+1 from me

On Wed, Dec 8, 2021 at 4:04 PM Larry Garfield 
wrote:

> After a great deal of offlist discussion, I hereby call an Entrance Vote
> on a Code Localization PSR.
>
> Specifically, the charter is here:
>
> https://github.com/php-fig/fig-standards/pull/1259/files
>
> Little has been firmly defined yet, of course.  That's why we're building
> a Working Group. :-)  But we have narrowed the scope to something we
> believe is manageable.
>
> We are open to, and still soliciting, additional WG members who have
> particular experience with major projects that have existing code
> localization systems.  Additional personnel MAY be added in the future,
> therefore.
>
> This is a Core Committee vote only.  Non-CC members, please sit tight. :-)
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/6b75ff3d-f909-49d3-a277-00e49d1fa8ae%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUOUSjwUfJsWYSmjpTQRqf%2BWavBRHKnCsuxRf%3D%2BPYdu2A%40mail.gmail.com.

Re: [VOTE][CC] PSR-16 (simple-cache) evolution

[Matthew Weier O'Phinney]

+1

On Thursday, October 14, 2021 at 2:12:28 AM UTC-5 alessand...@gmail.com 
wrote:

> Hello everyone,
> I hereby call a CC vote for the approval of the evolution of PSR-16 - 
> Simple Cache.
>
> The change in the spec is reviewable in this PR: 
> https://github.com/php-fig/fig-standards/pull/1252
> Inside the PR description you'll find the links to the two PR containing 
> the code changes:
>  - v2 adds parameters types, and makes CacheException extend \Throwable
>  - v3 (which obviously builds upon the previous) adds return types
>
> Both require PHP 8 at a minimum, since mixed and union types were needed, 
> and also to avoid issues when extending \Throwable (as it happened with the 
> evolution of PSR-11, see https://github.com/php-fig/container/issues/33).
>
> As per our bylaws:
>  - only Core Committee members may vote
>  - either For (+1), Against (-1), or Abstain (+0)
>  - quorum is 50%
>  - a 2/3 majority is required for passage.
>
> Votes take place over a period of two weeks (or at the reaching of 100% 
> quorum), so votes will be accepted up to 2021-10-28 10:00:00 UTC.
>

-- 
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/86a95578-7115-4ab2-86ec-b6e016267c0en%40googlegroups.com.

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

[Matthew Weier O'Phinney]

+1

On Tuesday, September 7, 2021 at 12:06:17 PM UTC-5 vin...@delau.nl wrote:

> This is the voting thread for the Core Committee only. There is a separate 
> thread for Project Representative 
>
> Larry Garfield has created a proposal for a change to the bylaws to 
> introduce PHP Evolving Recommendations. As part of that proposal, some 
> restructuring of the bylaws has been performed to be streamline the PSR, 
> PER and AR processes.
>
> The discussion thread can be found here: 
> https://groups.google.com/g/php-fig/c/gLNKg9jpRCU and some additional 
> discussions on Discord.
>
> The proposed change can be seen in the pull request: 
> https://github.com/php-fig/fig-standards/pull/1235 *(commit on day of 
> voting fdadde82c28d517b515b6aa87d42cb71daded4b4)*
>
>
> Per the voting protocol: https://www.php-fig.org/bylaws/voting-protocol/
>
>- Voting options are For (+1), Against (-1), or Abstain (+0)
>- Quorum is 50%, a 2/3 majority is required for passage.
>- Voting ends in two weeks, 2021-09-21 17:00:00 UTC
>
>
>

-- 
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/c2e39eec-a420-4355-ad69-80f74803b01fn%40googlegroups.com.

Re: Proposal: PHP Evolving Recommendations (PERs)

[Matthew Weier O'Phinney]

My main question is why the Util libraries would move to the PER process.

Currently, these have been developed to provide features complementary to a
given standard:

- cache-util and simplecache-util provides boilerplate that will be used in
most implementations, as well as default "in memory" implementations.
- http-util provides constants used for request methods and response status
codes

In each case, I'd argue they're less "evolving standards" as they are
libraries tracking common usage or tracking non-FIG standards to provide
commonly used artifacts. In other words, they are _libraries_, not
_recommendations_.

Otherwise, the rest of this looks fantastic! Thanks for putting this
together!

On Tue, Aug 10, 2021 at 4:49 PM Larry Garfield 
wrote:

> We've been talking about "living specs" for a long time.  Let's finally
> define a process for that:
>
> https://github.com/php-fig/fig-standards/pull/1235
>
> I won't resummarize it here, as the issue already does so.
>
> My expectation is that out of the gate, we'd see something like this:
>
> * PER-CodingStandards (uses PSR-12 as a basis, updating it for each new
> PHP release.)
> * PER-Cache Utils (maintains the cache-util and simplecache-util
> libraries.)
> * PER-HTTP (maintains the various PSR-7/15/17/18 util libraries.)
> * PER-DocBlocks (would replace PSR-19, the tag library, but NOT PSR-5, the
> parsing rules, which still need to get finished.)
>
> And should we decide that a "type library" (enums, etc.) is a reasonable
> thing for us to do, it would get its own PER as well.
>
> Discuss.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/0f07cf13-80e3-436d-b950-9cb7d926741b%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWyGG6Ypve1aaffwTwfwxrfn4do0c%3DJ2G4hZfY-Kr7wJA%40mail.gmail.com.

Re: [VOTE][CC] AzuraCast Membership vote

[Matthew Weier O'Phinney]

+1

On Sat, Jul 31, 2021, 10:05 AM Vincent de Lau  wrote:

> This thread is to collect votes on the AzuraCast Membership vote.
>
> Details:
>  - membership request:
> https://groups.google.com/g/php-fig/c/0fVYv0ha4Lo/m/SN7_aviaBAAJ
>  - proposed project representative: Felix Bachmann, which is the second
> lead developer.
>  - disclosure: Current Secretary Buster Neese is a project lead for
> AzureCast. He will continue to be secretary and thus will not represent
> AzuraCast.
>  - request sponsored by Larry Garfield 2 weeks ago:
> https://groups.google.com/g/php-fig/c/0fVYv0ha4Lo/m/SN7_aviaBAAJ
>
> Voting ends by 2021-08-14 17:00 UTC
>
> Voting options:  For (+1), Against (-1), or Abstain (+0)
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/d514a947-c254-4da0-af2c-6fba1dca4743n%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/CAJp_myXs4sEXLtAxwE6KryCXzKqQzRmDjPegTM%2BKFSD1XUTsKQ%40mail.gmail.com.

Re: PSR 7, PSR 15, PSR 17

[Matthew Weier O'Phinney]

ill resolve them for
you. In others, you will provide configuration detailing which
implementation the DI container should use. Others will have you create and
wire in a factory that will handle this detail (and this is where PSR-11
comes into play, as the factory can then retrieve instances from the
container to resolve dependencies).

The point, however, is that:

- Your middleware is decoupled from a specific framework or PSR-7/PSR-17
implementation. This allows both composition into different frameworks, as
well as substitution for its own dependencies.
- The code is declarative: you know what you need to provide it in order to
create an instance. This makes it testable and self-documenting. Your users
can find the PSR-7/PSR-17 combination that works for them and directly
instantiate the class using concrete implementations.

Am I understanding correctly that you're concerned with the "how do I get
my PSR-17 instances to my middleware" question? Particularly so that your
middleware can operate with multiple frameworks?

If that's the case, it's an open question. The PSR-11 group worked briefly
on a "service providers" spec that would have provided a standard way to
configure services for a PSR-11 container, but the problem discovered is
that DI containers vary widely in how they do their wiring.

Generally, I find that wiring dependencies into a framework tends to be
relatively trivial, which allows me to keep my packages focused on their
specific domain, and dependent only on the FIG specs for their HTTP layer.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXDj%2BkamG3859cRZOBR%2BBurK%3DaEtuiXNqY9DMFzX5zC9Q%40mail.gmail.com.

Re: PSR 7, PSR 15, PSR 17

[Matthew Weier O'Phinney]

On Tue, Jul 6, 2021 at 10:03 AM Adam Frederick  wrote:

> Please excuse my naivete, but upon making PSR 15 classes, I noticed an
> issue which I have not found satisfactorily resolved online or in this
> discussion group.
>
> The idea behind interoperability is to make sure things work on different
> systems.  Part of doing this is making sure there is a standard interface
> for normal activity.  Part of normal activity of a middleware would be
> altering the response body.  But, this presents a problem, since there is
> no standard method for going about creating a new stream within middleware.
>
> What is the standard for accessing a Psr\Http\Message\StreamInterface
> implementation from within middleware?
> - if I want to modify the body, I have to make a new stream (seeking and
> writing will often not fit)
> I would suggest, given the commonallity of not caring about streams in
> some middleware, the response gains two functions:
> 1. "withBodyString()"
> 2. possibly "getBodyString()" for expectation (just does __toString())
>

We deliberately chose not to provide methods for altering the message body
in either the request or response, and to specifically NOT force the idea
that content MUST be a string. There are many cases where strings do not
make sense (e.g.,returning images, binary archives, etc.), and limiting the
body content to a string made no sense. (On top of this, there are
performance considerations when the content gets sufficiently large, and
modeling the content as a stream allows PSR-7 implementations to do
optimizations that address those issues.) Since it is easy to model string
content with the StreamInterface, however, withBody() exists to allow you
to inject a custom StreamInterface instance into your request or response.

If you want to force a replacement, compose a PSR-17 StreamInterfaceFactory
into your middleware or handler, or instantiate a concrete PSR-7
implementation if you have specific needs you wish to address (e.g.,
modeling an image or binary archive)

Further, I would suggest two combined things for middleware:
> 1. ServerRequestInterface should also implement all the PSR 17
> interfaces.  Thus, middleware would access a factory like
> `$handler->createResponse()`.  This itself, the extended interface
> implementation, could be a PSR.
>

We deliberately chose not to have any of the PSR-17 interfaces extend from
the others. The reason is that there were too many combinations, and most
times, you only need 1, 2, or 3 capabilities, making it relatively easy to
compose them into your classes via dependency injection. If you find
yourself needing multiple capabilities regularly, create your own interface
that extends the set of interfaces you use regularly, and type-hint on that
in your middleware or handlers.


> 2. Middleware constructor interface dependencies should be resolved,
> allowing injection of factories.
> Combined, the ServerRequestInterface could just inject itself wherever a
> PSR 17 factory was required.  However, #2 puts the demand of interface
> dependency injection the the implementer.
>

Constructors cannot be specified in interfaces. Well, they can, but PHP
does not require implementations to honor them.

The reason is pretty simple: constructors should be specific to a given
class.

If we were to add a constructor to a middleware or handler interface, we'd
limit what could be injected, meaning that users would not be able to
inject other collaborators, such as a database, cache, etc.

And let's not forget: PSR-15 PREDATES PSR-17 anyways.

But the fact that PHP won't do it, and it would preclude having custom
constructors, means it's simply not an option.


>
> Without a standard, constructing middleware relies on knowing what the
> framework will do.  If the assumption is that middleware will have the
> factories injected, this should be stated in the standard as the standard.
>

There are no assumptions.

You can instantiate a response, URI, stream, etc. directly in your
middleware. (and thus tie yourself to a specific implementation)

Or you could inject factories, and use the factories to create the
instances.

It's up to you as a developer to define what your class needs to do its
work. PSR-7, PSR-15, and PSR-17 are very loosely coupled to allow exactly
this.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWhE9dVT5xP-W3z4n5iJZ3nZWt1dhQRqPdpy5Co0RnYXw%40mail.gmail.com.

Re: [Vote] PSR-3 Updates for Types

[Matthew Weier O'Phinney]

+1 from me.

On Fri, Jun 25, 2021, 9:36 AM Larry Garfield  wrote:

> Hear ye, hear ye!  I hereby open the vote on the type upgrades for PSR-3.
> Essentially, the vote is to merge and tag the following PRs:
>
> https://github.com/php-fig/fig-standards/pull/1231
> https://github.com/php-fig/log/pull/76
> https://github.com/php-fig/log/pull/77
>
> This is a Core Committee Vote, quorum 50% and requiring 66% approval.
>
> CC members, make with the voting.  And welcome to our new CC members and
> their first task on the job. :-)
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/8636f531-a2b5-41ea-bdda-ab6e9d189e21%40www.fastmail.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/CAJp_myWykOErGE3JhiiGaaFJQE3ZvNxzYm2V5J_KBGn%3DGg%3DBQw%40mail.gmail.com.

Re: [VOTE] Core Committee Election

[Matthew Weier O'Phinney]

1. Michelle Sanver
2. Larry Garfield
3. Woody Gilk
4. Matthew Weier O'Phinney
5. Alessandro Chitolina

On Thursday, June 10, 2021 at 10:42:31 AM UTC-5 alessand...@gmail.com wrote:

> Hello everyone,
> as specified in the previous thread (
> https://groups.google.com/g/php-fig/c/9Xeon2rP4SE), yesterday 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 2021, due to 
> Beau Simensen 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 
> five nominations (listed in chronological order of nomination):
>
>  - Larry Garfield
>  - Matthew Weier O'Phinney 
> <https://groups.google.com/d/topic/php-fig/PAnOZqE4QiQ/discussion>
>  - Michelle Sanver 
>  - Alessandro Chitolina
>  - Woody Gilk 
> <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 June 24th 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/681d9c3b-a207-4abe-bf32-8f8aa5bc4fc2n%40googlegroups.com.

Re: FIG-hosted enumerations

[Matthew Weier O'Phinney]

On Mon, May 24, 2021 at 3:41 PM Alexandru Pătrănescu 
wrote:

> On Mon, May 24, 2021 at 10:25 PM Michael C  wrote:
>
>> On Mon, 24 May 2021, 18:06 Larry Garfield, 
>> wrote:
>>
> On Mon, May 24, 2021, at 10:57 AM, Matthew Weier O'Phinney wrote:
>>>
>>>



> A http request method enum will not be complete for usage in all places
> because in fact a http method is just a string as I should be able to send
> BLABLABLA in my http client if I want to. Or receive it on my server. And
> because of that, they cannot be easily used as types in PSR-7, PSR-18. I
> think using string constants is fine here.
> Same thing for http response code; eventually Cloudflare will return a 524
> timeout response code that is not included. Well, for this actually it can
> be defined as an integer between 100 and 599 but that's not practical.
>
> So only StatusCategory enum looks good from my point of view.
>

When it comes to HTTP status codes and request methods, the IETF has left
them deliberately open-ended. That said:

- The specification allows for flexibility to add more within certain
parameters, and
- They have a process for petitioning to make new additions canonical.

What the current http-message-util does is codify the ones that are already
canonical. The primary reason to use them is not so much to consume and
validate an HTTP message, but to _create_ one. For example, with HTTP
clients, having the ability to select an enum for a given request method
helps prevent potential typos. If you are choosing to use a non-canonical
request method, you will need to deliberately steer clear from using the
enum, which in turn should trigger a bit of extra review on either your
part or your team's part. Similarly, for status codes, these are generally
of interest when creating the response. The way we've defined the constants
is to use their semantic name as the constant name, which in turn makes it
easier to indicate _intent_ as you create the response.

Yes, these _can_ also be used for validations, or if you want to see if a
request method or status code matches a known canonical value, but, as
noted, you should always be able to fall back to either range checks or a
regexp.

As such, I'd argue that having enums is a _starting point_ for message
validation, and an important one, and a _requirement_ for users creating
messages, with the understanding that they _can_ break out of the defined
values as needed, again, as long as they provide values that fit in the
standard ranges or ABNF.


>
>
>>
>>> There's likely other enums that it makes sense to have a single
>>> definition of, but don't fit neatly into a single existing PSR/util package.
>>>
>>> --
>>>   Larry Garfield
>>>   la...@garfieldtech.com
>>>
>>>
> Regards,
> Alex
>
> --
> 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/CAAwdEzBQvW3SaJH8fvzjN5rsSuEB280e2iab_JEcJ-cbVoesJQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAAwdEzBQvW3SaJH8fvzjN5rsSuEB280e2iab_JEcJ-cbVoesJQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWCuyx10TvjbV5diCWTUz44GUZ70b9h5WQAwQvDDctRug%40mail.gmail.com.

Re: FIG-hosted enumerations

[Matthew Weier O'Phinney]

On Mon, May 24, 2021 at 12:06 PM Larry Garfield 
wrote:

> On Mon, May 24, 2021, at 10:57 AM, Matthew Weier O'Phinney wrote:
> > You're aware we have constants defined already in the
> > fig/http-message-util library, right? Couldn't we just add an enum
> > later, once 8.1 is ready?
> >
> > (I'd argue that, in general, the *-util packages are a good place for
> these.)
>
> I am unsurprised to learn it. :-)
>
> For HTTP-related enums, that may be a good place to put it.  However,
> making them their own package may be helpful for those not already using
> PSR-7.  (Or, maybe we do want to put it in that package to encourage people
> to use PSR-7?  Interesting question.)


Currently, http-message-util only has a requirement on PHP, not on
psr/http-message. It's defining interfaces with constants for status codes
and request methods only.

That's not to say it would NEVER depend on psr/http-message, but the idea
behind it has been primarily to provide a vendor-neutral package for common
HTTP-related concerns, which is why I suggested it here.

I see good arguments for having them separate as well. It's hard for me to
gauge which direction would have greatest impact.


> The current PSRs (naturally) don't use any enums themselves, either.
>
> There's likely other enums that it makes sense to have a single definition
> of, but don't fit neatly into a single existing PSR/util package.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/b78ce3af-6a01-43fe-93af-83900665358b%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myV7sjREkt65yiT4uLwU5-%3D4nSDvghP%3DkLVgvaE9cJEHDQ%40mail.gmail.com.

Re: FIG-hosted enumerations

[Matthew Weier O'Phinney]

You're aware we have constants defined already in the fig/http-message-util
library, right? Couldn't we just add an enum later, once 8.1 is ready?

(I'd argue that, in general, the *-util packages are a good place for
these.)

On Fri, May 21, 2021 at 7:51 PM Larry Garfield 
wrote:

> Greetings, FIGlets.  (What does one call a FIG-involved person, anyway?
> FIGlet?  FIGment?)
>
> As you may be aware, PHP 8.1 is going to include support for
> Enumerations.
>
> https://wiki.php.net/rfc/enumerations
>
> I believe it would be beneficial for some common industrial enumerated
> types to have a common library, rather than everyone making their own.  The
> first examples that jump out at me are HTTP status codes and methods, which
> I have implemented here:
>
> https://github.com/Crell/EnumTools
>
> There are likely others, but I haven't come up with them yet.  (Obviously
> this code won't run on any released PHP version yet, but I'm pretty sure
> the syntax is right...)
>
> I am fine hosting these myself, but it occurs to me that they may be of
> more value if hosted by a more prominent organization, such as FIG.  Of
> course, it's not really a spec; a PSR for these wouldn't make any sense.
> It's more akin to the Util libraries that we maintain for various PSRs, but
> without an associated PSR.
>
> How do folks feel about FIG hosting such an enum collection?  We could
> make it one package or several, depending on how we decide to break it up.
> If FIG is OK hosting it I am happy to dump the enums I already build into
> whatever package FIG wants to use for them.
>
> Discuss.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/9fa79e25-5755-4f3f-9be9-3acc2ee67c6a%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWHWMXGvda6RHpFdaXqgLuG%2BTs2AZA1Ej2G2NQuAQoF%2BQ%40mail.gmail.com.

Re: [Internal][ELECTIONS] Request for nominations

[Matthew Weier O'Phinney]

I accept the nomination - thank you, Matteo!

On Mon, May 24, 2021 at 3:25 AM 'Matteo Beccati' via PHP Framework
Interoperability Group  wrote:

> Hi everybody,
>
> I nominate for CC:
>
> - Larry  Garfield
>
> - Matthew Weier O'Phinney
>
>
> Cheers
>
> On 20/05/2021 21:55, Alessandro Lai wrote:
> > Hello everyone,
> > and sorry for the delay. This is the month where we should be holding a
> > new cycle of elections, but instead I'm a little late, so I'll try to
> > kickstart the process now.
> >
> > We have those positions to fill which will be expired by the end of the
> > month:
> >   - 1 secretary position, currently owned by Asmir Mustafic
> >   - 4 CC Larry Garfield, Matthew Weier O'Phinney, Woody Gilk, Matteo
> Beccati
> >   - 1 CC position, which was left vacant by Beau Simensen last year
> >
> > Every one of the five which have an expiring term can express their
> > intention to run again for election, as anyone else is welcome to throw
> > their hat in the ring and help us out!
> >
> > As always,
> > *FAQ:*
> > Q: Who can be nominated?
> > A: Anyone! The secretaries of the PHP-FIG are basically administrative
> > clerks and community handlers. For more details, see
> > https://www.php-fig.org/bylaws/mission-and-structure/#secretaries
> > <https://www.php-fig.org/bylaws/mission-and-structure/#secretaries>
> > The CC members of the PHP-FIG are basically the technical steering
> > committee; citing the bylaw:
> > https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
> > <
> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee>
> >
> > Q: Who can nominate?
> > A: Citing the bylaw: "Candidates for Secretary or the Core Committee
> > must be nominated/proposed by an existing Project Representative or FIG
> > Secretary to be considered, and must publicly accept their nomination in
> > order to be valid. Prospective candidates may seek nominations in any
> > way they see fit."
> >
> > Feel free to reach out to me, the other two secretaries (Asmir & Buster)
> > or any other sitting PHP-FIG member to ask for a nomination or for
> > further informations.
> >
> > --
> > 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
> > <mailto:php-fig+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/php-fig/dce97b4a-2d1a-47ce-8e97-a3a7273d4789n%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/php-fig/dce97b4a-2d1a-47ce-8e97-a3a7273d4789n%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/6445e0cf-a1fc-190c-1486-fd864a7c63f1%40beccati.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXXpXs9iF_tysSCeObDMbvDmN1%3Dtdx%2BevynVpiwaXSTqg%40mail.gmail.com.

Re: [VOTE][CC] Bylaw CS update

[Matthew Weier O'Phinney]

+1

On Wed, Mar 31, 2021, 2:15 AM Alessandro Lai 
wrote:

>
> Hello everyone,
> this my seem a small formality, but we need a vote for a small bylaw
> amendment: https://github.com/php-fig/fig-standards/pull/1203
>
> Basically, we need to update the guidelines to follow PSR-12, since it
> deprecated PSR-2.
>
> As per our voting protocol:
> https://www.php-fig.org/bylaws/voting-protocol/
>
> This is a vote for the Core Committee only.
> Quorum is 50%.
> A 2/3 majority is required for passage.
> Voting ends in two weeks, at midnight UTC between 14th & 15th of April.
>
> I'll be opening a separate thread for project representative.
>
> --
> 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/0f947e00-2141-4ca6-910c-03b416878dcbn%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/CAJp_myXmSjA%2Bqc%3DpQXZYte5a-3ursBweZiq60-yrX2MJ%3DPtevA%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] Clock Interface PSR

[Matthew Weier O'Phinney]

+1

On Monday, March 15, 2021 at 6:35:58 PM UTC-5 demon...@gmail.com wrote:

> As the Sponsor for this new candidate PSR, I hereby call the Entrance Vote.
>
>
> Proposal PR: https://github.com/php-fig/fig-standards/pull/1224 
>
>
> Editor: Chris Seufert
> Sponsor:  Chuck Burgess - PHP-FIG
> Working Group:
> - Jérôme Gamez (kreait/clock)
> - Andreas Möller (ergebnis/clock)
> - Luís Cobucci (lcobucci/clock)
> - Pol Dellaiera
> - Ben Edmunds
> - Andreas Heigl (ergebnis/clock)
>
>
> Please do not reply to this topic if you are not a CC member. 
> --
>

-- 
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/5ef04838-1cbf-4445-971a-b5a5f9c08de3n%40googlegroups.com.

Re: [Vote] PSR-13 Link Errata

[Matthew Weier O'Phinney]

+1

On Wed, Feb 24, 2021, 3:51 PM Larry Garfield  wrote:

> Since there seems to be no dissension, no sense waiting any longer.
>
> I am hereby calling an Errata vote on the following Link fixes, including
> the linked (no pun intended) PRs.
>
> https://github.com/php-fig/fig-standards/pull/1222
>
> This is a CC Vote, requiring 2/3 to pass.  Voting will remain open until
> 10 March, unless all 11 CC members vote before then.  (Hint hint, folks.
> :-) )
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/bd840128-4b76-41f6-b028-a7a98d3da420%40www.fastmail.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/CAJp_myUv18LQFR7q6oz8PehcFabHJpgSRkq8xJo6YpacO2u8tA%40mail.gmail.com.

Re: [PSR-13] Fix for breaking bug

[Matthew Weier O'Phinney]

No additional feedback from me; I'm good with the proposed changes.

On Sun, Feb 14, 2021, 1:25 PM Larry Garfield  wrote:

> Michael Babker on Twitter recently alerted me to a bug in the new PSR-13
> release.  Specifically, it typed withAttribute(string $name, string
> $value), which is what the docblock had, but the spec said more than just
> strings were allowed for $value.  In particular, arrays and bool are called
> out specifically.  This is an API break.
>
> After discussing with implementers (mainly Symfony) to verify existing
> behavior, I offer this second errata with fixes to the spec.
>
> https://github.com/php-fig/fig-standards/pull/1222
>
> The PR there includes links to the package updates.
>
> As an errata this would require another Core Committee vote, which I will
> call in two weeks unless there are any objections before then, or if enough
> of the CC says to just go ahead and vote sooner.  (The two week discussion
> period is encouraged but not strictly required, so I'm willing to save time
> if everyone else is.)
>
> Also, please check and make sure there were no other issues introduced
> that we missed.  I'd hate to have to have another bug fix release. :-(
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/6b6e6605-58df-4d5f-988c-bec7c04ed67c%40www.fastmail.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/CAJp_myVKtdrMWeOpv9gNCTPa4-2YWce79cp-hTgznC%2BgkRU4Yg%40mail.gmail.com.

Re: [VOTE][PSR-11] Type Updates

[Matthew Weier O'Phinney]

Clearly, +1 from me.

On Fri, Feb 19, 2021 at 8:30 AM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Hi, everyone!
>
> On 2021-01-25, I opened the discussion period around updating PSR-11 per
> the PSR Evolution bylaw (https://www.php-fig.org/bylaws/psr-evolution/).
> The discussion centers around three related proposals:
>
> - https://github.com/php-fig/fig-standards/pull/1215 (the errata for the
> specification)
> - https://github.com/php-fig/container/pull/20 (the first step of the
> evolution, adding argument typehints, and modifying defined exception
> interfaces to extend Throwable)
> - https://github.com/php-fig/container/pull/28 (the second step of the
> evolution, adding return typehints where reasonable)
>
> Since opening the discussion period, the main question was whether the
> second step should have the specification target PHP 8 in order to pick up
> the "mixed" type. Consensus is that we should target PHP 7 releases at this
> time, as this will allow libraries to adopt the changes faster. (As an
> example, we're only just now getting around to having
> laminas-servicemanager typehint explicitly against PSR-11 and not
> container-interop; we'll be able to jump to the latest versions of the spec
> immediately as a result.)
>
> As the discussion period has passed the two-week minimum threshold, I now
> hereby open the vote.
>
> +1 to merge the patches and create the new releases
> -1 to leave things as-is
> +0 to abstain
>
> Thanks in advance, everyone!
>
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXRiwfuXYe0xawpy1yER-9z1Vz6nA0WLEwd%2B7kmV%3DhMqg%40mail.gmail.com.

[VOTE][PSR-11] Type Updates

[Matthew Weier O'Phinney]

Hi, everyone!

On 2021-01-25, I opened the discussion period around updating PSR-11 per
the PSR Evolution bylaw (https://www.php-fig.org/bylaws/psr-evolution/).
The discussion centers around three related proposals:

- https://github.com/php-fig/fig-standards/pull/1215 (the errata for the
specification)
- https://github.com/php-fig/container/pull/20 (the first step of the
evolution, adding argument typehints, and modifying defined exception
interfaces to extend Throwable)
- https://github.com/php-fig/container/pull/28 (the second step of the
evolution, adding return typehints where reasonable)

Since opening the discussion period, the main question was whether the
second step should have the specification target PHP 8 in order to pick up
the "mixed" type. Consensus is that we should target PHP 7 releases at this
time, as this will allow libraries to adopt the changes faster. (As an
example, we're only just now getting around to having
laminas-servicemanager typehint explicitly against PSR-11 and not
container-interop; we'll be able to jump to the latest versions of the spec
immediately as a result.)

As the discussion period has passed the two-week minimum threshold, I now
hereby open the vote.

+1 to merge the patches and create the new releases
-1 to leave things as-is
+0 to abstain

Thanks in advance, everyone!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myVHMjmrQmk5LP_5rvdLYzbTPquQJSX%2BDE%2B2KS4UzbsJ2A%40mail.gmail.com.

Re: [DISCUSSION][PSR-11] Type Updates

[Matthew Weier O'Phinney]

On Mon, Jan 25, 2021 at 10:09 AM Larry Garfield 
wrote:

> On Mon, Jan 25, 2021, at 9:39 AM, Matthew Weier O'Phinney wrote:
> > We've had a couple of PRs on the php-fig/container repository ready for
> > the 1.1 and 2.0 releases, per the PSR Evolution bylaw
> > (https://www.php-fig.org/bylaws/psr-evolution/).
> >
> > - https://github.com/php-fig/container/pull/20 would target 1.1, and
> > adds parameter typehints, as well as updates exception interfaces to
> > extend the Throwable interface.
> > - https://github.com/php-fig/container/pull/28 would target 2.0, builds
> > on #20, and adds return typehints.
> >
> > As both David Negrier (original editor) nor Mathieu Napoli (current
> > editor) have indicated they do not have time currently to push these
> > forward, as a CC member, I'm opening the discussion period, and, in two
> > weeks, will open a vote (assuming we have addressed any reported
> > issues/problems with the patches).
>
> Left one note on the second PR.
>
> I think we also need a PR to the spec and metadoc to make a note of the
> change.  (See the PSR-6/13 PR sets.)
>

Already did those in June last year:
https://github.com/php-fig/fig-standards/pull/1215

It was what prompted the PHP Evolution bylaw discussion and ratification. :)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myVpP4h%3DQf3PMXH2soVr%2BOeoaS7F%2B-_gcQgVEC2kX2fCMA%40mail.gmail.com.

[DISCUSSION][PSR-11] Type Updates

[Matthew Weier O'Phinney]

We've had a couple of PRs on the php-fig/container repository ready for the
1.1 and 2.0 releases, per the PSR Evolution bylaw (
https://www.php-fig.org/bylaws/psr-evolution/).

- https://github.com/php-fig/container/pull/20 would target 1.1, and adds
parameter typehints, as well as updates exception interfaces to extend the
Throwable interface.
- https://github.com/php-fig/container/pull/28 would target 2.0, builds on
#20, and adds return typehints.

As both David Negrier (original editor) nor Mathieu Napoli (current editor)
have indicated they do not have time currently to push these forward, as a
CC member, I'm opening the discussion period, and, in two weeks, will open
a vote (assuming we have addressed any reported issues/problems with the
patches).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myW9HktJhL4oJkdJqVpu0Rxfr466qjW00Gv2qWFL52h1tg%40mail.gmail.com.

Re: [Vote] [PSR-6] Type updates

[Matthew Weier O'Phinney]

+1

On Sat, Jan 16, 2021 at 11:09 AM Larry Garfield 
wrote:

> I hereby call a vote of the Core Committee to approve the following PRs to
> update PSR-6 to use modern PHP typing capabilities, as previously discussed.
>
> This is a Core Committee vote requiring a 50% quorum and 2/3 majority,
> with voting ending on 30 January.
>
> CC members, please cast your votes.
>
> Spec: https://github.com/php-fig/fig-standards/pull/1220
> Step 1: https://github.com/php-fig/cache/pull/23
> Step 2: https://github.com/php-fig/cache/pull/24
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/09b03692-a9d4-4f14-a931-7723aaf94d19%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUa%3DTTxusFHsiyk95RwAHb7Wy6B%3DqWsdKpM4nqp5OSJCA%40mail.gmail.com.

Re: [Vote] [PSR-13] updates

[Matthew Weier O'Phinney]

+1

On Sat, Jan 16, 2021 at 11:07 AM Larry Garfield 
wrote:

> I hereby call a vote of the Core Committee to approve the following PRs to
> update PSR-13 to use modern PHP typing capabilities, as previously
> discussed.
>
> This is a Core Committee vote requiring a 50% quorum and 2/3 majority,
> with voting ending on 30 January.
>
> CC members, please cast your votes.
>
> Step 1: https://github.com/php-fig/link/pull/6
> Step 2: https://github.com/php-fig/link/pull/7
> Spec: https://github.com/php-fig/fig-standards/pull/1199
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/fb854aac-a513-4d19-b2f0-1a4740e7d1e8%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWXOW5r%2BGcFt-mr0E%3Dnz6ffoQDG2HZ9nZdVQdwbOm7CCw%40mail.gmail.com.

Re: FIG CoC - take 2

[Matthew Weier O'Phinney]

>
>
> --
> regards,
> Lukas
>
> --
> 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/CAEFKHaGofSXVPrMN1djpzLuD4tbaaZCXJAgi5f1VKN8ZEhh6Ag%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAEFKHaGofSXVPrMN1djpzLuD4tbaaZCXJAgi5f1VKN8ZEhh6Ag%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXExY5KQvRS6ktwdmbWGCZ4WhiGBCV30Y--UYM%3Dzc6E3w%40mail.gmail.com.

Re: [VOTE][Projects] TYPO3 Membership vote

[Matthew Weier O'Phinney]

+1, Laminas Project

On Friday, July 3, 2020 at 2:17:43 AM UTC-5 alessand...@gmail.com wrote:

> [VOTE][CC] TYPO3 Membership vote
>
> This thread is to collect votes on the TYPO3 Membership vote.
>
> Details:
>  - membership request: 
> https://groups.google.com/d/topic/php-fig/qDOyOuLuoKc/discussion
>  - proposed project representative: Benni Mack, which is project lead
>  - request sponsored by Matteo Beccati 2 weeks ago: 
> https://groups.google.com/d/msg/php-fig/qDOyOuLuoKc/HtwMXZ_jBgAJ
>
> Quorum: none
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY PROJECT REPRESENTATIVES CAN VOTE HERE, see current list: 
> https://www.php-fig.org/personnel/#member-projects
>

-- 
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/cd11-5a3e-4a06-a655-558ee352ad72n%40googlegroups.com.

Re: [VOTE][Projects] Errata bylaw update

[Matthew Weier O'Phinney]

+1, Laminas Project

On Thursday, July 9, 2020 at 3:47:58 AM UTC-5 alessand...@gmail.com wrote:

>
> Since the mandatory two weeks are passed on the discussion (
> https://groups.google.com/g/php-fig/c/CObJmc5jDcE), I'm hereby calling a 
> Project Representatives vote for this bylaw change.
>
> As always, there is no quorum, majority is 2/3.
> Vote will end July 23rd, 23:59:59 UTC.
>
> THIS THREAD IS FOR PROJECT REPRESENTATIVE VOTES ONLY
>

-- 
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/0707a580-b545-408b-b92e-715b3e7855b0n%40googlegroups.com.

Re: [VOTE][CC] Errata bylaw update

[Matthew Weier O'Phinney]

+1

(as it's a blocker for me calling a vote on the PSR-11 changes!)

On Thu, Jul 9, 2020 at 3:46 AM Alessandro Lai 
wrote:

> Since the mandatory two weeks are passed on the discussion (
> https://groups.google.com/g/php-fig/c/CObJmc5jDcE), I'm hereby calling a
> CC vote for this bylaw change.
>
> As always, quorum is 50%, majority 2/3.
> Vote will end July 23rd, 23:59:59 UTC.
>
> THIS THREAD IS FOR CORE COMMITTEE VOTES ONLY
>
> --
> 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/718c7275-04ae-4e60-a4ec-6330cd893ed0n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/718c7275-04ae-4e60-a4ec-6330cd893ed0n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXNqpwVRuCkDoGy9X9Br8GA-PDKEsBRs1uHu5A5BC%3DK2g%40mail.gmail.com.

Re: [VOTE][CC] TYPO3 Membership vote

[Matthew Weier O'Phinney]

+1 from me

On Fri, Jul 3, 2020, 2:16 AM Alessandro Lai 
wrote:

> This thread is to collect votes on the TYPO3 Membership vote.
>
> Details:
>  - membership request:
> https://groups.google.com/d/topic/php-fig/qDOyOuLuoKc/discussion
>  - proposed project representative: Benni Mack, which is project lead
>  - request sponsored by Matteo Beccati 2 weeks ago:
> https://groups.google.com/d/msg/php-fig/qDOyOuLuoKc/HtwMXZ_jBgAJ
>
>
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/cf05addb-2600-483c-ae7c-8766cf6f27c2o%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/CAJp_myUiAmX_FGQn2mNG_xx6SaL1D_6tCmYrH6JsBqzLxCs11A%40mail.gmail.com.

Re: PSR-11 — interface evolution

[Matthew Weier O'Phinney]

On Thu, Jun 18, 2020 at 3:16 PM Larry Garfield 
wrote:

> On Thu, Jun 18, 2020, at 2:05 PM, Matthew Weier O'Phinney wrote:
>
> > > Also: Matthew, why the first release would be 2.0? Can't we declare it
> a 1.1 to make the transition smoother, as suggested by the bylaw?
> >
> > I got confused on that by Larry's blogpost, but you're absolutely
> correct.
>
> Per both bylaw and blog post, both 1.1 and 2.0 are valid approaches
> depending on the details.  In this case it would mainly depend on whether
> we consider changing from docblock "string" to type definition "string",
> which does technically now prevent stringable objects when they probably
> worked before, an API break.
>
> That's a case-by-case question we get to sort out.  I agree with MWOP that
> in this case no one has any damned business using a stringable object here
> to begin with, so it's not really a BC break in any meaningful sense.  So,
> either way could work.
>
> MWOP: remember to also make a PR for the PSR itself to note the change in
> errata.  I think the PSR-13 PR had something you could steal from.
>

Done:

- https://github.com/php-fig/fig-standards/pull/1215


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUPZ-1uKZhDDS4v8%2BeV97DBgtfoY9O0bB9QQPffTSOrBg%40mail.gmail.com.

Re: PSR-11 — interface evolution

[Matthew Weier O'Phinney]

On Thu, Jun 18, 2020 at 1:17 AM Alessandro Lai 
wrote:

> Mixed will be in PHP 8: https://wiki.php.net/rfc/mixed_type_v2
>
> Also: Matthew, why the first release would be 2.0? Can't we declare it a
> 1.1 to make the transition smoother, as suggested by the bylaw?
>

I got confused on that by Larry's blogpost, but you're absolutely correct.

I've updated the PRs such that the first one now targets a v1.1.0, and the
second 2.0.0.

I tend to agree with Larry that waiting for PHP 8 for the "mixed" type
doesn't offer much, and since implementations can add it without breaking
compatibility, I'd rather we move forward. If nothing else, but to
demonstrate PSR evolutions concretely. :)


>
> Il giorno giovedì 18 giugno 2020 00:23:00 UTC+2, Larry Garfield ha scritto:
>>
>> On Wed, Jun 17, 2020, at 2:41 PM, Matthew Weier O'Phinney wrote:
>> > Per the discussions started earlier this year, I've opened two pull
>> > requests to "evolve" the PSR-11 ContainerInterface to use explicit type
>> > hints:
>> >
>> > The first — https://github.com/php-fig/container/pull/27 — updates the
>> > psr/container package to require PHP 7.2, and adds the `string`
>> > typehint to the `$id` parameters of each of the `has()` and `get()`
>> > methods. The intention is for this to be tagged as v2.0, and would
>> > allow implementations:
>> >
>> > - Immediate forwards compatibility, as the covariance/contravariance
>> > rules of PHP 7.2 allow implementations to accept wider type ranges for
>> > parameters.
>> > - The ability to make themselves forwards compatible with a later
>> > release by adding return type hints, as this is be covered by the same
>> > covariance/contravariance rules (implementations can return a narrower
>> > set of types than their parent types).
>> >
>> > The second — https://github.com/php-fig/container/pull/28 — builds on
>> > the previous, and updates the psr/container package to add a return
>> > type of `bool` to the `ContainerInterface::has()` method. The intention
>> > is for this to be tagged as v3.0.
>> >
>> > These changes follow the specification verbatim, as the `$id` arguments
>> > are documented as strings. Further, I do not think this is a place
>> > where the proposed `Stringable` interface for PHP 8 comes into play;
>> > the context when pulling from a service container is generally to
>> > provide either a class name or a string service name; using a class to
>> > represent that is a sufficiently edge case that I see no good argument
>> > to wait for PHP 8 so we can do `string|Stringable` in this particular
>> > specification.
>> >
>> > Finally, I have not proposed a return typehint for `get()`, as the
>> > specification as written explicitly allows `mixed`. Not having a return
>> > type is the technically correct approach in this context.
>> >
>> > If there are no objections, I'd like to get these moved forward.
>> >
>> > Thanks!
>>
>> This all makes sense to me, and the PRs look good.
>>
>> The one note I'd have is that an explicit `mixed` type hint is probably
>> going up for vote for PHP 8 very soon; I don't know if that justifies
>> waiting on that for the second PR/3.0 release.  For "mixed" probably not as
>> it doesn't really offer much, but I mention it for completeness.
>>
>> --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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/de471524-60de-4f44-a28d-6bacff46ad32o%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/de471524-60de-4f44-a28d-6bacff46ad32o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myVOeRuwamoFn0hbWo%2B7htFOMdx8kXkA4uzBwgYDgwuKBQ%40mail.gmail.com.

PSR-11 — interface evolution

[Matthew Weier O'Phinney]

Per the discussions started earlier this year, I've opened two pull
requests to "evolve" the PSR-11 ContainerInterface to use explicit type
hints:

The first — https://github.com/php-fig/container/pull/27 — updates the
psr/container package to require PHP 7.2, and adds the `string` typehint to
the `$id` parameters of each of the `has()` and `get()` methods. The
intention is for this to be tagged as v2.0, and would allow implementations:

- Immediate forwards compatibility, as the covariance/contravariance rules
of PHP 7.2 allow implementations to accept wider type ranges for parameters.
- The ability to make themselves forwards compatible with a later release
by adding return type hints, as this is be covered by the same
covariance/contravariance rules (implementations can return a narrower set
of types than their parent types).

The second — https://github.com/php-fig/container/pull/28 — builds on the
previous, and updates the psr/container package to add a return type of
`bool` to the `ContainerInterface::has()` method. The intention is for this
to be tagged as v3.0.

These changes follow the specification verbatim, as the `$id` arguments are
documented as strings. Further, I do not think this is a place where the
proposed `Stringable` interface for PHP 8 comes into play; the context when
pulling from a service container is generally to provide either a class
name or a string service name; using a class to represent that is a
sufficiently edge case that I see no good argument to wait for PHP 8 so we
can do `string|Stringable` in this particular specification.

Finally, I have not proposed a return typehint for `get()`, as the
specification as written explicitly allows `mixed`. Not having a return
type is the technically correct approach in this context.

If there are no objections, I'd like to get these moved forward.

Thanks!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXXuHj2YOicMVV6W_U_4vacrc1UBLQXsvLTzLA1i3AH3w%40mail.gmail.com.

Re: [PSR-7] Error in mult-file upload code sample

[Matthew Weier O'Phinney]

You're correct - please file an issue on the tracker to resolve this.

On Sun, May 10, 2020 at 5:53 AM 'Florian Reuschel' via PHP Framework
Interoperability Group  wrote:

> This issue is very similar to [PSR-7] Files behavior wrong description
> <https://groups.google.com/forum/?fromgroups#!msg/php-fig/0g8ztOtZVHE/bOq9PwiSCgAJ;context-place=searchin/php-fig/psr-7%7Csort:date>
>  (which
> has been fixed in the spec as far as I can tell):
>
> The $_FILES code sample for
>
> 
>
>
> is inaccurate. It states that the according $_FILES structure looks like
> this:
>
> array (
> 'my-form' => array (
> 'name' => array (
> 'details' => array (
> 'avatar' => array (
> 0 => 'my-avatar.png',
> 1 => 'my-avatar2.png',
> 2 => 'my-avatar3.png',
> // ...
>
>
> But according to the input name, the nested key should be avatars instead
> of avatar.
>
> Or am I missing 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/d69c4ac9-6ed3-4279-9f68-7d70eb266b06%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/d69c4ac9-6ed3-4279-9f68-7d70eb266b06%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myVq%3D744R6TW-6peRvO4FAYMtKe4-aSnoXhJ%2BamxQ50s2A%40mail.gmail.com.

Re: PSR Evolution, PSR-13, and nuance

[Matthew Weier O'Phinney]

od
> enough for us to pin to a given language version, given the subtle changes
> that may sometimes result.
>
> I open the floor for comments, especially from the Core Committee folks.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/c20ce8d8-d633-4629-b8b8-54742a11adcb%40www.fastmail.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUrb_CsCrnzOT-YiFE-aBNFUxx5TDD-rhtJ-3pjFviJoA%40mail.gmail.com.

Re: RequestInterface

[Matthew Weier O'Phinney]

On Sat, Jan 18, 2020 at 4:30 PM Anton Fedonjuk 
wrote:

>  When retrieving the request-target with getRequestTarget(), by default
>> this method will use the URI object and extract all the necessary
>> components to construct the *origin-form*.
>>
>
> Please don't copy-paste PSR-7 - it's not answer. In given situation we sent 
> wrong request because absolute-form in $requst->getRequestTarget() != 
> (string) $requst->getUri().
>
> RequestInterface::getUri() return UriInterface instance or you talk about 
> strval(new Uri('')) MUST return '/'?
>
> I wasn't copy-pasting. I was describing the purpose behind the
`withRequestTarget()` method, and how it differs from the composed URI.

The request-target is used _only for creating the string version of the
HTTP message_. It CAN differ from the URI. The URI should be used by
clients to determine where to connect.

It is up the user to ensure that the request-target does not specify a
different scheme + authority when using the absolute-form or
authority-form. We did not include checks for variances in these, because
technically the HTTP spec (RFC 7230, https://tools.ietf.org/html/rfc7230)
allows this (primarily for use with proxies).

As you note, `$request->getRequestTarget() !== (string) $uri`. This is
correct. The DEFAULT for `getRequestTarget()` is to return an origin-form,
which is the path and query string only. The origin-form does not allow for
an empty string; a single slash ("/") is the minimum allowed; from section
5.3.1 of RFC 7230: "

   If the target URI's path component is
   empty, the client MUST send "/" as the path within the origin-form of
   request-target.

(Of note: origin-form is the most common, and the recommended form in RFC
7230.)

If you want the absolute-form, you must set it explicitly: $request =
$request->withRequestTarget((string) $request->getUri())



> воскресенье, 19 января 2020 г., 0:51:54 UTC+3 пользователь Matthew Weier
> O'Phinney написал:
>
>>
>> I think you're not understanding the purpose of the request-target within
>> a request.
>>
>> Section 1.4 of the PSR-7 spec details the purpose, and how different
>> values are interpreted. The point to understand, however, is that these
>> serve a different purpose than the composed UriInterface. The UriInterface
>> is used by a client in order to determine the protocol, port, and hostname
>> so that the client can connect to the server in question. The
>> request-target is the value used as the second segment of the request line
>> when transmitting the request.
>>
>> In PSR-7, if no request-target is provided, then the string form of the
>> URI fills in as an absolute-form request-target.
>>
>> Because the request-target can take a variety of forms that are not
>> compliant with a UriInterface implementation (e.g., asterix-form, for
>> OPTIONS requests; authority-form, for CONNECT requests; origin-form, which
>> is typically only the pat; etc.), we allow setting it _separately_ from the
>> URI. This means that setting it MUST NOT change the URI, as the point is
>> that this is to customize the request line, and otherwise not affect how a
>> client connects to the server.
>>
>> You ask "how URI can be not available?" When using PSR-17, it MUST be
>> present. However, if you are using a specific implementation, it's entirely
>> possible to construct a fully empty request. This is why we indicate the
>> default behavior when that happens.
>>
>> --
>> Matthew Weier O'Phinney
>> mweiero...@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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/1e548e05-1232-45d2-b17c-9db03e6fa5a5%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/1e548e05-1232-45d2-b17c-9db03e6fa5a5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWUGcF-GmgyOMDfC-325dg-T5bo4MiB2NEzi_X395mFmQ%40mail.gmail.com.

Re: RequestInterface

[Matthew Weier O'Phinney]

On Fri, Jan 10, 2020 at 1:17 PM Anton Fedonjuk 
wrote:

> $request->withRequestTarget('http://www.example.org/pub/page.html');
> method must change "Host" header and/or URI?
>
> I ask because *all* the PSR-7-compatible packages that I saw don't do
> this. I think it's happened because note added only for withUri.
>

I think you're not understanding the purpose of the request-target within a
request.

Section 1.4 of the PSR-7 spec details the purpose, and how different values
are interpreted. The point to understand, however, is that these serve a
different purpose than the composed UriInterface. The UriInterface is used
by a client in order to determine the protocol, port, and hostname so that
the client can connect to the server in question. The request-target is the
value used as the second segment of the request line when transmitting the
request.

In PSR-7, if no request-target is provided, then the string form of the URI
fills in as an absolute-form request-target.

Because the request-target can take a variety of forms that are not
compliant with a UriInterface implementation (e.g., asterix-form, for
OPTIONS requests; authority-form, for CONNECT requests; origin-form, which
is typically only the pat; etc.), we allow setting it _separately_ from the
URI. This means that setting it MUST NOT change the URI, as the point is
that this is to customize the request line, and otherwise not affect how a
client connects to the server.

You ask "how URI can be not available?" When using PSR-17, it MUST be
present. However, if you are using a specific implementation, it's entirely
possible to construct a fully empty request. This is why we indicate the
default behavior when that happens.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWSgfFVhDN4_U7iJOwyRY3D30kd70zUirWcQrsTeGHZFg%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

+1 from Zend Framework (soon to be Laminas!)

On Mon, Nov 11, 2019 at 3:49 AM 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 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
> <https://groups.google.com/d/msgid/php-fig/fc771d51-13e8-411f-8b0e-eae400f92897%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myU%2Bqg5ow3cr3qq7qKY1x4t5nWxL%3DJAu99YCMNkjHuRCmg%40mail.gmail.com.

Re: HttpFactoryInterface maybe? (PSR-17)

[Matthew Weier O'Phinney]

On Mon, Nov 11, 2019 at 5:16 PM Anton Fedonjuk 
wrote:

> It's shortes and guarantees full support PSR-7, PSR-17:
> setHttpFactory(HttpFactoryInterface $factory);
> getHttpFactory(): HttpFactoryInterface;
>
> now:
> setRequestFactory(RequestFactoryInterface $factory);
> getRequestFactory(): RequestFactoryInterface;
> ...
> setUriFactory(UriFactoryInterface $factory);
> getUriFactory(): UriFactoryInterface;
>

We actually debated this when forming the specification, and decided
against it.

The rationale was that in most cases, you will need a subset of all
factories. As an example, in server-side applications, the only place
you'll generally need the request, URI, and/or uploaded file factories is
at the application entrypoint. And when you are in a handler or middleware,
you'll need the response factory, and _maybe_ the stream factory at most.
(The "maybe" part has to do with whether (a) you're returning any actual
content, and (b) whether you need special capabilities in your content
stream, vs. just writing to it. In that latter case, you'll likely be
depending on an _implementation_ anyways.)

It would be rare that you would ever need a factory that combines all
capabilities. Even with an HTTP client, generally speaking the consumer
will want the factories for creating a request, but the responsibility of
creating the response would be entirely up to the client itself. Even when
creating the request, quite often only a subset is necessary:
createRequest() can create the URI and body stream, and in most scenarios,
what they do is enough.

Our take was that we could try and second-guess which combinations would be
useful, but the list would become expansive, and users would be confused
about what they should type-hint on: should they hint on the most specific
they need, or one or more interfaces representing "union" types? We felt
users should indicate _what they need_, specifically.

That said: there's always the fig/http-factory-util package for managing
some of these, and our thought was that users could propose some of those
union types there. If those become widely used, we can create an additional
spec that codifies them.


> вторник, 12 ноября 2019 г., 2:01:44 UTC+3 пользователь Alexander Makarow
> написал:
>>
>> What would be the benefit having it?
>>
>> вт, 12 нояб. 2019 г., 00:28 Daniyal Hamid :
>>
>>> 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 <https://github.com/guzzle/psr7/blob/master/src/HttpFactory.php>
>>> and Nyholm
>>> <https://github.com/Nyholm/psr7/blob/master/src/Factory/Psr17Factory.php>
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/d1087758-ceac-4b9a-a1e2-107553d9c18c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/d1087758-ceac-4b9a-a1e2-107553d9c18c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/ebc77935-c27e-4604-9294-783010c0f2a0%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/ebc77935-c27e-4604-9294-783010c0f2a0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myWEk2Jsgb2KMBNQawaiq6uz2cV%2BaMX4dEmEHe9cjdM52g%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

+1

Really nice job pulling all the various concerns together, and I appreciate
how well you listened to feedback from the various parties (myself
included).

On Mon, Nov 11, 2019 at 3:48 AM 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/c2879540-00c4-4dcd-b4d9-6c4fba50c8fc%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/c2879540-00c4-4dcd-b4d9-6c4fba50c8fc%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUqY2bPba5OufMVP8DYzceH4v7kLngMjtRKWEeJbjUn3A%40mail.gmail.com.

Re: Naming Convention For Acronyms In Method Name (As Per PSRs)

[Matthew Weier O'Phinney]

On Thu, Oct 17, 2019 at 12:57 PM Daniyal Hamid 
wrote:

> Hi Guys,
>
> We were having a debate at work about the proper casing for acronyms in
> method names, but upon searching through PSR-1, 2 and 12, I couldn't find
> anything specific on the topic. What's the group's take on this?
>

I see it vary from project to project. Some will PascalCase the acronym,
others will keep it all upper-case. I think that's a preference that
individual projects should likely spell out for themselves, as it's deeply
subjective.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myU4cRUv1TBK1Qvk-38jwowpaifwHDihkwP2EOB5bCp0RQ%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

On Sat, Oct 12, 2019 at 9:25 AM Anton Fedonjuk 
wrote:

> *Not reusable/resettable objects it`s potential problem in future.*
> *Yes, we can send  factories or add empty instances, but it's harder than
> add method to reset content.*
>
>
Resetting content means _resetting the StreamInterface instance used with
the message_.

This is by design. Since the `withBody()` method returns a new instance, it
ensures that changes to the original body stream do not propagate to the
current instance. If you want to reset content for the purpose of writing
to it, _it should not matter what kind of stream was used before_.

If it does, then your code is tied to an _implementation_, and, if that's
the case, you should directly instantiate objects from that implementation,
using the signature of their constructors.

If it doesn't (and it _shouldn't_), using a composed PSR-17
StreamFactoryInterface will get you a new stream that you can use
immediately, and you're now no longer tied to a specific implementation.


> My current code:
>
> abstract class HttpGateway extends Gateway
> {
> protected $client;
> protected $request;
> protected $dataSeparator;
>
> public function __construct(ClientInterface $client,
> RequestFactoryInterface $factory)
> {
> $this->client = $client;
> // Checks properties because extended class can overwrite them.
> if (! $this->request) {
> $this->request = $factory->createRequest('GET', $this->getUrl
> ());
> }
> if (! $this->dataSeparator) {
> $this->dataSeparator = ini_get('arg_separator.output') ?: '&';
> }
> }
>
> protected function sendRequest(array $data)
> {
> $data = http_build_query($data, '', $this->dataSeparator,
> PHP_QUERY_RFC3986);
> if ($this->request->getMethod() == 'POST') {
> $request = clone $this->request;
> $request->getBody()->write($data);
> } else {
> $uri = $request->getUri()->withQuery($data);
> $request = $this->request->withUri($uri, true);
> }
> $response = $this->client->sendRequest($request);
> return $this->parseResponse($response);
> }
> }
>
> *As result: I can`t use PSR-7 without PSR-17, than why not merge it and
> adds exception iterfaces?*
>

You can use PSR-7 without PSR-17 just fine. We did it in Expressive by
providing prototype factories, which users could override by registering
their own versions that would return instances from the PSR-7
implementation they chose.

PSR-17 _simplifies_ this by providing a standard.

But you can totally use PSR-7 without PSR-17. As an example, a _library_
that consumes PSR-7 instances directly _does not care about the factories
at all_, only the PSR-7 instances.

There's reasons to keep them separate.

At the application level, yes, you will generally use them in tandem. But,
again, it's not required.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myXkq2Tz6Dd5bmPRKSsy7OSyzuZFTjFfV6yftbPY%2BEX%2BOQ%40mail.gmail.com.

Re: PSR-7: real problems at working with abstract objects

[Matthew Weier O'Phinney]

On Mon, Oct 14, 2019 at 9:34 AM Anton Fedonjuk 
wrote:

>
> *Third-party PSR-7-compatible packages - A, my package - B. Package B can
> use any package A and *
> *doesn't depend on the implementation of package A. *
> *PSR class implements PSR interface (ex: class Stream implements *
> *StreamInterface).*
>
> For beginning: I read the recommendations/meta and understand why PSR
> team came to this decision.
>
> But in real: this recomendation works only for only for well-known package
> A whose structure you know. I will not be able to use* any* package A in
> package B.
>

Please explain what you are trying to do with one package that you cannot
do with another. Without this information, we're running on your assertion,
without any evidence, which makes it impossible to understand what the
problem is that you're facing.


> "PSR-7-compatible" does not imply that package A also implements PSR-17. 
> Personal
> statistics: at least half of packages A not PSR-17-compatible.
>

This is perfectly fine. PSR-7 packages do not need to implement PSR-17, and
vice versa. It is up to the application developer to compose PSR-17
factories in their container that will provide PSR-7 instances for you.
Instances provided by PSR-17 packages will be PSR-7 compatible. You can mix
and match, but you will generally want to ensure that the PSR-17 package
you use returns instances from the same PSR-7 implementation you chose for
your application.


> I can't create new (or reset) PSR classes (in package B) from not 
> PSR-17-compatible
> package A i.e I can't realize Prototype, Factory patterns.
>

PSR-17 provides factories, plain and simple. That's all. It does so in
predictable ways. But what it provides is fairly minimal, and targeted at
the bare minimum of PSR-7 capabilities. If you want specialized streams
(e.g., callback streams, binary streams, etc.), you will need to use your
own factories or specialized PSR-7 instances (e.g., Diactoros provides a
variety of specialized responses such as JsonResponse, XmlResponse, etc.).

You can provide your own factories for providing prototypes (this is what
Expressive did until version 3).

All of this is by design: it provides the _minimum_ API necessary for
interop.


> I see a solution to these problems in merging PSR-7 and PSR-17 in new PSR
> as in PSR-12. This will allow:
> update current interfaces:
>add return type declarations for methods where it need
>

There is a proposal at the FIG level for evolving specifications to adopt
both return type hints and argument type hints. If this is ratified,
there's no need for a new spec.


>add methods and fix current docBlock's:
>  StreamInterface::truncate($length)
>  UriInterface::withQuery($query) @param iterable $query,
> UriInterface::withQueryLine($query) @param string $queryand + getters
>

You'll need to provide justification for each of these. We chose not to
implement most of these, and have information in the metadocument detailing
why.


>add constants: constant with request methods, protocols
>

This latter is provided by the fig/http-message-util package. It is
purposely NOT in the spec to allow us to update it as new response status
codes and methods are ratified by the IETF.


> add interface/class exceptions
>

We chose not to do these as well, and I believe that info is also in the
metadocument.

While I see _some_ value in having PSR-7 and PSR-17 merged, I also see
value in keeping them separate. I'd like to see more justification
presented before we consider walking that path.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myV%3Dt-GhCfnz%3DL4L7jTjYGsPSuwrysheO97-TVT8Uq2ZKA%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

On Thu, Oct 10, 2019, 6:42 PM Anton Fedonjuk 
wrote:

> Class contains method setRequest(RequestInterface $request), his abstact
> code:
> Request body already sets: $request->getBody()->write('...');
> I want send this request with other body content, but dont know how:
> 1. StreamInterface don't have methods as PHP ftruncate()
> 2. Constructor not defined in StreamInterface: can't use
> $request->withBody() because dont know how create clone of that Steam
> object without contents.
>

To provide new contents, you provide a new body to the request, which means
using a new StreamInterface instance.

To get a new StreamInterface instance, you either instantiate I've
directly, per the PSR-7 *implementation* you have installed, or you use a
PSR-17 StreamFactoryInterface instance to create it. This is something you
would compose into your class as a constructor dependency.

In each case, you need an *implementation* of one or both of the specs
installed, which is already likely the case.

In the first case, if using Diactoros, your code might look like this:

$request = $this->getRequest()
->withBody(new \Zend\Diactoros\Stream('php://temp', 'wb+'));

In the second, it would look like this:

$request = $this->getRequest()
->withBody($this->streamFactory->createStream());

>From there, you can call on the stream's write() method. Alternately, if
using the factory, create the entire stream *with contents* to save
yourself the step.

Regarding your point that there is no StreamInterface constructor,
the constructor is not defined in any of the interfaces because:

- We did not want to restrict how implementations wrote constructors.
- PHP ALWAYS allows classes implementing interfaces to override the
signature of a constructor.

As such, you always have to look at how the *implementation* to determine
the signature of constructors.

This is one large reason PSR-17 exists - to standardize how instances of
psr-7 interfaces are created.

Regardless, each of the above examples give you an instance with an empty
body.


> --
> 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/84a56774-1dbf-4ec3-b906-b29e8b322add%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/CAJp_myUCo3reWr8z_WOHNvs1JNOVxPTkD_gps2d_fKh0ZnHiqQ%40mail.gmail.com.

Re: [VOTE] [Accept] PSR-12 Extended Coding Style Guide

[Matthew Weier O'Phinney]

+1 from me.

On Fri, Jul 26, 2019 at 11:10 AM Chris Tankersley 
wrote:

> Finally, after a very long review period and much discussion and tweaking,
> I think we are finally ready for the acceptance vote for PSR-12.
>
> The specification can be found here:
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
>
> And the meta document here:
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
>
> Thank you to everyone involved!
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAL9n4XNXae2wfGbwERNEF-68M8cxrvxgeu%2BjKSdvb2HravQ%3D7w%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAL9n4XNXae2wfGbwERNEF-68M8cxrvxgeu%2BjKSdvb2HravQ%3D7w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAJp_myUWPOR50yBiMsB8R2tP7%2BZ90VC7CSa0k%2BpO_8ofCuMQbA%40mail.gmail.com.

Re: [VOTE] [Accept] PSR-12 Extended Coding Style Guide

[Matthew Weier O'Phinney]

Hi Chris!

I don't recall seeing a review period. There was one some time ago
(February), but my understanding was that it was retracted once some
feedback came in (most recent was May). IIRC, we're supposed to reopen the
review period if we don't go directly to the acceptance vote.

Regardless, can you summarize what changes were made since then, and what,
if any, feedback was addressed?

Thanks!

On Fri, Jul 26, 2019, 10:10 AM Chris Tankersley 
wrote:

> Finally, after a very long review period and much discussion and tweaking,
> I think we are finally ready for the acceptance vote for PSR-12.
>
> The specification can be found here:
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
>
> And the meta document here:
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
>
> Thank you to everyone involved!
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAL9n4XNXae2wfGbwERNEF-68M8cxrvxgeu%2BjKSdvb2HravQ%3D7w%40mail.gmail.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/CAJp_myWGb%3DCfYwhW7YRB5ADUx%3DJ%3Dov%3Dy4tp-dq0eTKPrOaTJFQ%40mail.gmail.com.

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

[Matthew Weier O'Phinney]

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

I really like this idea!

The one part I don't think is possible is the line "implementors should be
able to easily support all majors of the package ... it should be
recommended."

Why?

Because some language changes are not compatible with previous versions.

As an example, if we have the following in the original spec:

interface Car
{
/**
 * @param string $brand
 * @return self
 */
public function withBrand($brand);
}

and v2 then updates to take advantage of scalar type hints and return type
hints:

interface Car
{
public function withBrand(string $brand) : self;
}

then an implementation MUST choose one version or the other. Why?

- If it targets the v1 spec, it will be incorrect for v2, as the typehints
are missing entirely.
- If it adds typehints to follow v2, it's invalid for usage with v1,
because v1 defined no typehints. (This is not a problem if only an RTH is
added; however, as soon as any arguments have typehints, it is.)

(See https://3v4l.org/JbEJI for an example; you can comment out one or the
other implementation to see the errors each produces.)

Consumers generally won't need to care much, as the _usage_ will be
identical. They can safely pin to multiple versions of the PSR package.
However, the packages _providing the implementations_ will have to do some
nasty dynamic polyfill stuff to make it work, and it will only get harder
the more versions they need to support. I'd argue implementors should bump
major versions to support new versions of the PSR package.

-- 
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_myV0%2B-cEKFyNdTZxZX-2rOVLpTvP0pvU5F5iJO4m_aYDkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Core Committee Election

[Matthew Weier O'Phinney]

For Zend Framework (soon to be Laminas):

1. Matthew Weier O'Phinney
2. Adam Englander
3. Benni Mack
4. Larry Garfield
5. Woody Gilk
6. Beau Simensen
7. Matteo Beccati

On Sun, May 5, 2019 at 4:48 PM Alessandro Lai 
wrote:

> 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
> <https://groups.google.com/d/msgid/php-fig/9e1624fa-b968-43c6-923f-5d507774703e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAJp_myVHA-AY-cvfpVQO9YK4TiOi2%3D44idLW_NWJFddh1%2Bv8dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

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
> <https://link.getmailspring.com/link/754a7090-1136-4f47-ba10-2ceaccf92...@getmailspring.com/0?redirect=https%3A%2F%2Ftwitter.com%2Fmwop&recipient=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t>)
> 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
> <https://groups.google.com/d/msgid/php-fig/754A7090-1136-4F47-BA10-2CEACCF92B37%40getmailspring.com?utm_medium=email&utm_source=footer>
> .
> 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/CAJp_myUC1Jnx%2BE6RHRM%3D8NuTbQM%2BXDDoa7j6Cju-LBbLMbcXrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-7 Documentation Errata Corrige

[Matthew Weier O'Phinney]

On Sun, Apr 14, 2019 at 10:22 AM Antonio Cota  wrote:

> https://www.php-fig.org/psr/psr-7/ 1.3 Streams paragraph:
>
> > [...] StreamInterface is used in order to hide the implementation
> details when a stream of data is read from or written to. [...]
>
> I think it should be:
>
> > [...] StreamInterface is used in order to hide the implementation
> details *of where* a stream of data is read from or written to. [...]
>

Honestly, they're semantically close in meaning, and I don't think it
warrants an errata.


-- 
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_myVB_tgYOSD9qx%2B59v%2BeBa0VPdy0LJqGXcYfWo4TL4quQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[CC][Nomination] Woody Gilk

[Matthew Weier O'Phinney]

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.

Re: Confusion with PSR-7 UriInterface

[Matthew Weier O'Phinney]

On Thu, Apr 4, 2019 at 6:44 AM  wrote:

> Okay thanks. Mine implementation is going to be a general implementation,
> but with http/https/ftp/sftp the same path rules apply so what I'm doing is
> throwing an exception if changing to scheme where the path no longer
> validates.
>
> One question still remains on key=value query normalization, I can't seem
> to find an RFC on it or even a best practices for when there are duplicate
> keys.
> It seems some give priority to first, some give priority to last, some
> serialize them as a key=[value1,...,valueN] comma delimited array, some
> only do the array thing if the were presented as key=[value1]&key=[value2]
>
> Is there any kind of RFC or best practices guide for dealing with
> key=value pairs in the context of GET query?
>
> Obviously for the email scheme one can't serialize them as an array, but
> for HTTP/HTTPS they potentially could be and sometimes are, I just don't
> know if that is a frowned upon practice or not or what is *suppose* to be
> done. Currently I just throw an InvalidArgument exception for duplicate
> keys but if there are normalization rules I would rather follow them.
>

IIRC, IETF 3986 says that how they are normalized is up to the consumer
(which could be the server, php-fpm, a library, etc.)

Maybe see what PHP's parse_str() does?


On Saturday, March 30, 2019 at 9:50:18 AM UTC-7, pipfros...@gmail.com wrote:
>>
>> Blocker Confusion -
>>
>> The interface method:
>>
>> public function withPath($path);
>>
>> requires
>>
>> * @throws \InvalidArgumentException for invalid paths.
>>
>> However in https://tools.ietf.org/html/rfc3986#section-3.3 I do not see
>> what constitutes an invalid path.
>>
>> Is that a bug in the interface or it it expected that the class validate
>> the path according to the RFCs specific to each scheme?
>>
>> The problem I have with the latter interpretation is twofold:
>>
>> A) It makes it impossible to create a class that is generic in scope for
>> scheme, which means if class A implements the interface and class B
>> implements the interface you can't just swap class A for B in use because
>> they may implement different schemes.
>>
>> B) The "withScheme($scheme)" method requires producing an identical
>> instance where only the scheme has changed, but that may then result in a
>> new instance where the path is not valid for that particular scheme because
>> all the other properties of the class must be retained.
>>
>> So... are we really suppose to validate the path according to the RFC for
>> the scheme or would it be better to leave validation of the the path part
>> of the URI to tools specific to the scheme by the software that uses the
>> class to build a URI?
>>
> --
> 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/85e91d49-aa8d-4567-92c4-3649d42ba2b1%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/85e91d49-aa8d-4567-92c4-3649d42ba2b1%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAJp_myWyTTggWg1doiafXMSu4mtALPTLgUOY1YLA%3DPFvTrkm8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Confusion with PSR-7 UriInterface

[Matthew Weier O'Phinney]

On Sat, Mar 30, 2019 at 11:50 AM  wrote:

> Blocker Confusion -
>
> The interface method:
>
> public function withPath($path);
>
> requires
>
> * @throws \InvalidArgumentException for invalid paths.
>
> However in https://tools.ietf.org/html/rfc3986#section-3.3 I do not see
> what constitutes an invalid path.
>

That section defines the ABNF (Augmented Backus-Naur Form, a specification
for defining syntax rules), and defines what character sequences are
allowed for paths. When we indicate that the path must be valid, we are
indicating it must be valid per the ABNF defined in that section.

It is specifically NOT requiring that you validate that the path is valid
_for the domain or the scheme_, only that it is well-formed.


> Is that a bug in the interface or it it expected that the class validate
> the path according to the RFCs specific to each scheme?
>

The path segment of a URI has a single ABNF, as defined in the section you
link. I'm not quite sure what you're inferring here, but I'm wondering if
perhaps you're looking at a different specification?

The problem I have with the latter interpretation is twofold:
>
> A) It makes it impossible to create a class that is generic in scope for
> scheme, which means if class A implements the interface and class B
> implements the interface you can't just swap class A for B in use because
> they may implement different schemes.
>
>
> B) The "withScheme($scheme)" method requires producing an identical
> instance where only the scheme has changed, but that may then result in a
> new instance where the path is not valid for that particular scheme because
> all the other properties of the class must be retained.
>
> So... are we really suppose to validate the path according to the RFC for
> the scheme or would it be better to leave validation of the the path part
> of the URI to tools specific to the scheme by the software that uses the
> class to build a URI?
>

PSR-7 only defines URIs for the HTTP and HTTPS schemes. This was a very
deliberate choice, as we felt defining something that was generic enough to
fit any possible scheme was out-of-scope for a specification focusing on
HTTP messages. As such, the ABNF for path specifications is the same, and
there's no reason to revalidate the path.

There was some talk at one point of creating a general specification for
URI interface(s), but nobody has moved forward as far as a proposal at this
point.

-- 
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_myXLA-Ce5MV6Tm%2BPd9%2B81SczpAc-_y2ppTZiBMoFsZn70g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-7 URI Interface userInfo question

[Matthew Weier O'Phinney]

On Mon, Mar 18, 2019 at 8:37 AM Robert Crous 
wrote:

> I understand that `Uri(some_url)->userInfo` returns the result of
> `parse_url(some_url)[user]` (and then optionally append ':' . [pass]).
>
> My question is: why are there no setters and getters available for `user`
> and `pass`?
>
> I can't see any reason why having getters/setters available for user +
> pass would disrupt anything and it seems fairly odd that the decision was
> made to replace this with `getUserInfo` and `withUserInfo`.
>
> But is there a specific reason why this was done?
>

There is a reason: because the user-info segment of a URI is not limited to
user/pass combinations, and user/pass combinations are, in fact,
deprecated, per RFC 3986 Section 3.2.1:
https://tools.ietf.org/html/rfc3986#section-3.2.1

This is also why we do not provide separate "getter" methods for the
user/pass. When using that functionality, the onus is on the user to know
that both fields are present, and to split them manually. (Having
additional methods did not make sense, since the functionality can be
accomplished in userland code using the available methods.)

As such, we provide the following methods only:

- getUserInfo(), which will return the full user-info segment
- withUserInfo(string $user, ?string $password = null) : UriInterface,
which allows creating and returning a new instance with the provided
user-info data.

As noted elsewhere in this thread, the majority of interfaces in the
specification are marked immutable, and the way to create variants of any
given instance is via the various `with*()` methods. This decision is
documented in the meta document.


And if not- is there any way this can be added to the spec for the URI
> interface?
>
> Kind Regards,
>
> Rob
>
> --
> 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/b45e38a2-222c-4b3a-afb6-bd2f130547f7%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/b45e38a2-222c-4b3a-afb6-bd2f130547f7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAJp_myXOJ2C6xADFcQYWS0G_MGA_jvAMQjVP_e0nmKaY1ijzpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

+1

On Sun, Mar 10, 2019, 1:31 PM Cees-Jan Kiewiet  wrote:

> The REVIEW period for the proposed PSR-14, Event Dispatcher, hit its
> minimum required length on 27 February 2019. We continued the period since
> then to make sure nothing came up and some minor concerns where raised as
> PR, 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 24 March 2019, or when all CC members have cast
> their vote, whichever comes first.
>
> The relevant materials are as follows:
>
> - Specification:
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md
>
> - Metadocument:
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-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
>
>
> Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor
>
> --
> 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/b46fe9d1-0290-4b31-9629-03ffe109b709%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/CAJp_myWWDdpiuOGaYG8cyCFh0UdYhthg%3DBYiSM9r92-wd6eiAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-14 Event Dispatcher

[Matthew Weier O'Phinney]

ub.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
>>> > >>
>>> > >> During the Review phase, acceptable changes to the specification
>>> include wording, typographical fixes, and clarifications. If you feel major
>>> changes are necessary or have, please bring your arguments/questions to the
>>> list under this thread. If any major changes are considered, we will return
>>> to the Draft phase.
>>> > >>
>>> > >> The Review period will end no sooner than 27 Jan 2019 at 11:59pm.
>>> At that time, if the working group can demonstrate two viable trial
>>> implementations, and no need for major changes, I will call for an
>>> Acceptance Vote.
>>> > >>
>>> > >> Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor
>>>
>>> Core Committee members: How shall the WG interpret your silence? :-)  As
>>> approval or indifference?
>>>
>>> If approval, please let us know that you're approving so we know not to
>>> worry when it comes time to call a vote. :-)
>>>
>>> Beuller?
>>>
>>> --Larry Garfield
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to php-fig+u...@googlegroups.com.
>>> To post to this group, send email to php...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/ac14ce13-e39b-4227-b9d7-68c7ef6bd834%40www.fastmail.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/cbabeda2-7fbf-41a4-a05e-d065aec4e143%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/cbabeda2-7fbf-41a4-a05e-d065aec4e143%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAJp_myVqYDwZGXn%3DHPmNsg48FiTzTdUorS55K-vzjAMv69nXtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Adopt Code Manifesto

[Matthew Weier O'Phinney]

ught to your attention, heed it.
>3. We are our biggest assets. None of us were born masters of our
>trade. Each of us has been helped along the way. Return that favor when you
>can, and be respectful of others' place in their journey.
>4. *Respect defines us*. Treat others with respect and compassion
>unless they abuse that trust. Make your discussions, criticisms and debates
>from a position of respect for the humanity of all involved. Ask yourself,
>is it true? Is it necessary? Is it constructive? Anything less is missing
>the mark.
>5. *Reactions require grace*. Angry responses are valid, but neither
>abusive language nor harmful actions are acceptable. If something happens
>which concerns you, address it directly or report it, but be respectful.
>Allow the organizers time to discuss the incident with the offender and
>possibly correct the issue.
>6. *To err is human; always be iterating*. You might not intend it,
>but mistakes do happen and contribute to build experience. Tolerate honest
>mistakes, and don't hesitate to apologize if you make one yourself.
>Remember, apologies are hallow without also correcting the behavior.
>
>
>
> On Tue, Jan 29, 2019 at 9:06 AM Chuck Burgess 
> wrote:
>
>> Looking over both the manifesto and the covenant, I didn't really notice
>> anything that would conflict between the two, if we wanted to simply
>> include *both*... doing so would just be presenting an intersection of
>> their requirements.  Is that too much verbiage overall?  Maybe just link to
>> both, since they are standalone entities (that seem to be versioned, or at
>> least versionable)?  Stating that we want to abide by both, then
>> delineating how those in FIG positions can act to enforce, ... maybe that
>> would cover the concerns mentioned?
>> CRB
>> *about.me/ashnazg <http://about.me/ashnazg>*
>>
>>
>> On Thu, Jan 24, 2019 at 7:54 AM Larry Garfield 
>> wrote:
>>
>>> On Wed, Jan 23, 2019, at 1:58 PM, Lukas Kahwe Smith wrote:
>>> >
>>> > On Wed, 23 Jan 2019 at 20:42, Matthew Weier O'Phinney
>>> >  wrote:
>>> > >
>>> > >
>>> > > On Wed, Jan 23, 2019 at 2:49 AM Lukas Kahwe Smith <
>>> sm...@pooteeweet.org> wrote:
>>> > >> On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield <
>>> la...@garfieldtech.com> wrote:
>>> > >>  >
>>> > >>  > Greetings, FIGians.
>>> > >>  >
>>> > >>  > This has been bounced around in back channels on and off for a
>>> while, so I think it's finally time to make it official. I propose that we
>>> officially adopt the Code Manifesto[1] as our official standard of behavior.
>>> > >>  >
>>> > >>  > Specifically, as follows:
>>> > >>  >
>>> > >>  > https://github.com/php-fig/fig-standards/pull/1143
>>> > >>  >
>>> > >>  > WHY?
>>> > >>  >
>>> > >>  > First off, I want to be clear that I am NOT making this
>>> recommendation in response to any current issue. I am not aware of any
>>> current issue that would require invoking or even discussing invoking the
>>> guidelines listed here. FIG has been delightfully boring in that regard for
>>> quite some time and, "good lord willin' and the creek don't rise", it will
>>> stay that way.
>>> > >>  >
>>> > >>  > That of course is the best time to discuss such matters, as they
>>> can be looked at from a reasonably objective and dispassionate perspective.
>>> The definition of expected behavior of current official FIG members is
>>> quite vague and wishy washy (by design), and having clearer up-front
>>> expectations is good should the need ever arise.
>>> > >>  >
>>> > >>  > WHY THE MANIFESTO?
>>> > >>  >
>>> > >>  > A number of organizations and projects have of late adopted the
>>> "Contributor Covenant" as their code of conduct. My concern with the
>>> Covenant is that it is a very negative document; in contrast, the Manifesto
>>> provides guidelines of good behavior rather than an enumeration of bad
>>> behavior. In my experience, a positive document tends to encourage the
>>> desired behavior better than a negative one.
>>> > >>
>>> > >>  We had a brief discussion on this point via 

Re: Proposal: Adopt Code Manifesto

[Matthew Weier O'Phinney]

On Wed, Jan 23, 2019 at 2:49 AM Lukas Kahwe Smith 
wrote:

> On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield 
> wrote:
> >
> > Greetings, FIGians.
> >
> > This has been bounced around in back channels on and off for a while, so
> I think it's finally time to make it official.  I propose that we
> officially adopt the Code Manifesto[1] as our official standard of behavior.
> >
> > Specifically, as follows:
> >
> > https://github.com/php-fig/fig-standards/pull/1143
> >
> > WHY?
> >
> > First off, I want to be clear that I am NOT making this recommendation
> in response to any current issue.  I am not aware of any current issue that
> would require invoking or even discussing invoking the guidelines listed
> here.  FIG has been delightfully boring in that regard for quite some time
> and, "good lord willin' and the creek don't rise", it will stay that way.
> >
> > That of course is the best time to discuss such matters, as they can be
> looked at from a reasonably objective and dispassionate perspective.  The
> definition of expected behavior of current official FIG members is quite
> vague and wishy washy (by design), and having clearer up-front expectations
> is good should the need ever arise.
> >
> > WHY THE MANIFESTO?
> >
> > A number of organizations and projects have of late adopted the
> "Contributor Covenant" as their code of conduct.  My concern with the
> Covenant is that it is a very negative document; in contrast, the Manifesto
> provides guidelines of good behavior rather than an enumeration of bad
> behavior.  In my experience, a positive document tends to encourage the
> desired behavior better than a negative one.
>
> We had a brief discussion on this point via IRC a few days ago. While
> such a document is a very small step forward, I personally think that
> the manifesto lack of naming problematic behavior is its biggest
> weakness, since it does very little to assure people that you are
> willing to name problematic behavior when it occurs, when you cannot
> even do so in the rules you publish.
>

I tend to agree with Lukas here, and have a bit of background to share.

A few years ago, Zend Framework adopted Code Manifesto to govern our
projects, for many of the same reasons Larry has stated: we like the
emphasis on positive guidelines of acceptable behaviour over an enumeration
of punishments for bad behaviour.

In practice, it's been problematic, for a number of reasons.

When unacceptable behaviour is observed, there's no clear contact to report
to. This leaves people either waiting and hoping somebody will step in, or
leaving the conversation to avoid the person.

Additionally, when somebody does step in (generally somebody with
moderation rights in whichever community forum the interactions are
occurring on), there's then questions:

- What behaviour was observed? How is it against the code?
- What direction should be provided to the user to prevent future issues?
- Is banning necessary? If so, how long? Should it ever be permanent?

Essentially, a code without an explicit process for calling out violations
and dealing with them makes addressing problems entirely subjective and at
the whim of those with moderation powers.

In terms of reporting, reporting MUST be able to be done anonymously, to
prevent retribution by the accused against the accuser; people who abuse
the rules are simply more likely to retaliate. Without this, members of the
community have no safe way to report that prevents further abuse.

In sum: I love the Code Manifesto as a guideline for how people should
interact within the community. However, it's not a code of conduct; a code
of conduct needs to outline the specific behaviours that will trigger
actions, how to report these safely, and what actions may be taken. These
are required to ensure a safe and fair process.

-- 
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_myVEKMD17e8amh-cKJo7qkHq6fDL5o7api1WTd18KsDZFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Vote][PSR-14] Readiness Vote

[Matthew Weier O'Phinney]

+1 from me

On Wed, Jan 16, 2019 at 4:22 PM Larry Garfield 
wrote:

> I, Larry Garfield, being of debatably sound mind and body, acting in my
> capacity as Editor of PSR-14, do hereby call a Readiness Vote for PSR-14,
> "Event Dispatcher".
>
> This vote is for members of the PSR-14 Working Group only, who are:
>
> Larry Garfield
> Cees-Jan Kiewiet
> Elizabeth Smith
> Matthew O'Phinney
> Ryan Weaver
> Benni Mack
>
> If you are not one of those people, please do not vote on this thread.
>
> The spec to be voted on is here:
>
>
> 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
>
> Additionally, a Composer package with the spec-defined interfaces is here
> (the
> 0.7.0 tag):
>
> https://github.com/php-fig/event-dispatcher
> https://packagist.org/packages/psr/event-dispatcher
>
> A set of utilities created by the Working Group (that are not part of the
> spec
> proper but account for common shared use cases) is here (the 0.7.2 tag):
>
> https://github.com/php-fig/event-dispatcher-util
> https://packagist.org/packages/fig/event-dispatcher-util
>
> Additionally, the Working Group offers the following implementations as
> demonstration of the viability of the specification:
>
> * Tukio (https://github.com/Crell/Tukio, 0.7.2 tag): A full
> implementation of
> the specification written by Larry Garfield
> * Phly Event Dispatcher (https://github.com/phly/phly-event-dispatcher):
> A
> full implementation of the specification written by Matthew O'Phinney
>
> Additionally, Matthew has produced a prototype implementation that uses
> the
> Swoole extension to defer listener execution asynchronously.  From Matthew:
>
> --
> - https://github.com/weierophinney/mwop.net/blob/master/src/Blog/Listener/
> BlogPostEventListenersDelegator.php
> <https://github.com/weierophinney/mwop.net/blob/master/src/Blog/Listener/BlogPostEventListenersDelegator.php>
> - this shows three listeners on the same
> event being attached to a provider. The last one on there is interesting,
> because:
> - https://github.com/weierophinney/mwop.net/blob/master/src/Blog/Listener/
> CacheBlogPostListenerFactory.php#L21-L27
> <https://github.com/weierophinney/mwop.net/blob/master/src/Blog/Listener/CacheBlogPostListenerFactory.php#L21-L27>
> it gets decorated as a queueable
> listener, and operates async.
>
> Another one:
> - https://github.com/weierophinney/mwop.net/blob/master/src/Contact/
> SendMessageListenerDelegator.php
> <https://github.com/weierophinney/mwop.net/blob/master/src/Contact/SendMessageListenerDelegator.php>
> - this registers a single listener for an
> event to a provider. This listener is also interesting:
> - https://github.com/weierophinney/mwop.net/blob/master/src/Contact/
> SendMessageListenerFactory.php#L37-L43
> <https://github.com/weierophinney/mwop.net/blob/master/src/Contact/SendMessageListenerFactory.php#L37-L43>
> - because it, too, gets decorated as a
> queueable listener, and operates async.
>
> How does that work?
> - https://github.com/phly/phly-swoole-taskworker/blob/master/src/
> QueueableListener.php#L40
> <https://github.com/phly/phly-swoole-taskworker/blob/master/src/QueueableListener.php#L40>
> - enqueues a `Task` instance with the listener as
> the handler, and the event as the sole argument. Swoole then runs it via
> its
> task workers.
> --
>
> The vote will remain open for 2 weeks ending on 30 January, or until all 6
> WG
> members have voted, whichever comes first.  If it meets a 2/3 majority,
> the
> spec will go to the Core Committee for Review, moderated by our Sponsor,
> Cees-
> Jan.  It will be eligible for an Acceptance Vote one month from that date.
>
> --Larry Garfield
> PSR-14 Editor
>
> PS:  \o/
>
> --
> 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/4353796.rg0NdbNKlp%40vulcan.
> 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/CAJp_myU-SLgRHXyY8y2tz%3D8Gr9hE%2B%3DsgMTWHSLeWBFVsJDqQDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14] Meeting Summary - 2019-01-09

[Matthew Weier O'Phinney]

On Thu, Jan 10, 2019 at 8:24 PM  wrote:

> Thanks Matthew!
>
> I'm a little iffy about type hinting $events as 'object', a marker
> EventInterface seems much better here, no? I know you guys probably debated
> a lot about this and got to this point, and I understand that the former is
> better for backward compatibility and supporting existing implementations,
> but `EventInterface` has more of a semantic value, no?
>

We did indeed go back and forth on this one a lot.

When surveying the various event systems, what we found was a solid mix of
those that have specific event types, and those that allow passing
arbitrary objects. The latter are interesting, because they allow you to
pass your existing business objects as events, which allows them to remain
agnostic of the fact that they may be used in that fashion. If we forced
implementation of an interface, this would break such use cases.

In then end, we did not find enough justification for the marker interface
to exist, while there were plenty of good reasons to omit it. Additionally,
if PHP eventually fully supports its stated covariant
parameters/contravariant return types for all methods, this would allow
developers to provide more specific types to the arguments and/or return
values safely.

On Thursday, January 10, 2019 at 7:48:04 PM UTC+5, Matthew Weier O'Phinney
wrote:
>
>
>
> On Thu, Jan 10, 2019 at 6:01 AM  wrote:
>
>> Glad to see this is in working mode again.
>>
>
> As Larry noted, we have been diligently working all along; however, we had
> a lot of back and forth and discussion happening that precluded any changes
> to the interfaces. Once the discussions were resolved, we could report back
> again. There simply was no point in giving a blow-by-blow each week until
> decisions were made.
>
>
>> I would love to know if there are any other example implementations done
>> for the latest spec? Thanks!
>>
>
> Yes - https://github.com/phly/phly-event-dispatcher is the implementation
> I've been working on. I'm also planning on doing a patch against
> zend-eventmanager soon to detail one way we may be able to adopt it in a
> future release.
>
>
> On Thursday, January 10, 2019 at 10:13:58 AM UTC+5, Larry Garfield wrote:
>>
>> It's been a while since I've filed one of these, I'm afraid.  Fall was a
>> mix
>> of deep discussion that wasn't complete yet, conferences and other
>> schedule
>> conflicts that slowed us down, and then the holidays.  I didn't want to
>> present a discussion that was still actively engaged in sausage making
>> and
>> still subject to active change on a moment's notice, so, well, here we
>> are.
>> However, I'm going to try and summarize the various changes we've made to
>> PSR-14 in the last few months now that we're settled down again and, I
>> think,
>> in a very good place.  This summary is not chronological, but in the
>> order I
>> think makes the most sense collectively from our last update.
>>
>> * After a great deal of discussion, we decided to remove the
>> Message/Notifier
>> portion of the spec.  In the end, we decided that there just wasn't
>> enough
>> existing prior art for us to analyze and determine good edge case
>> handling for
>> that approach.  In particular, our nominal target for that pathway,
>> Symfony's
>> Messenger component, on further review we determined to be a completely
>> different use case anyway that was not even what we were targeting here,
>> and
>> thus irrelevant to PSR-14 entirely.
>> * That in turn allowed us to remove several nouns from the spec (yay),
>> which
>> meant that we could fold the "Event" term back into the only "thing that
>> gets
>> passed".  The "Task" terminology is now gone.  There's just Events,
>> Dispatchers, and Providers.
>> * However, after looking into Laravel in more detail and examining the
>> way
>> Listener callables and Providers were defined already, we realized that
>> the
>> bulk of the use cases for Messages -- that is, potentially deferrable/
>> asynchronous unidirectional communication -- could be handled in a
>> similar
>> fashion to Laravel's "ShouldQueue" marker interface on the *listener*
>> (not the
>> event).  Specifically, listeners are abstractly defined enough that they
>> can
>> still defer actions themselves, or Providers can add a deferring wrapper
>> themselves, in appropriate situations.  That is, we can cover just as
>> many use
>> cases as before but in a more flexible way with less cer

Re: [PSR-14] Meeting Summary - 2019-01-09

[Matthew Weier O'Phinney]

> The specification text is now up to date, modulo a few bits of fiddling
> we're
> still working on that shouldn't have any impact on the interface
> signatures
> themselves:
>
>
> 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
>
> The following composer package for the interfaces themselves is also ready
> to
> use, on the 0.7 tag:
>
> https://packagist.org/packages/psr/event-dispatcher
>
> And a corresponding util package, at the 0.7.1 tag (sorry):
>
> https://packagist.org/packages/fig/event-dispatcher-util
>
> (We'll add a few more utilities to the util package before it actually
> ships,
> mostly provider tooling.)
>
> And a fully complete implementation to try is available here (0.7.1 tag):
>
> https://packagist.org/packages/crell/tukio
>
> We're collectively pretty happy with where we are at this point, and
> encourage
> all interested parties to try out the code above.  We're planning another
> meeting for next week and if no other issues are raised by then plan to
> call a
> Readiness Vote at that time.
>
> --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/03bd4868-e71d-4bb7-a6be-d44505414590%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/03bd4868-e71d-4bb7-a6be-d44505414590%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAJp_myWau-4k5s%3Dr5hRVpRZ%2BU1iTtAFxPJXOy8Zcoi16S3i0Hw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

On Tue, Dec 11, 2018 at 12:14 PM Hari K T  wrote:

> Hi all,
>
>
>> The package consists of interfaces - so there's nothing really to test,
>> and there's no CI or anything like that set up. (and it wouldn't work if
>> there were, because there's no dependency on PHPUnit although it's
>> extending that class.)
>>
>> This test is for implementations - so these are literally tests for other
>> packages.
>>
>> So yes, I'm entirely in favor of these tests residing in those packages -
>> or a utility package, if the tests happen to be useful to other packages.
>> (I'd go as far as naming that package with "phpunit" in the name, since
>> these facilities aren't generic utilities - they're specific to phpunit,
>> and the base-class depends on it.)
>>
>> > nothing is broken *right now*, so we don't need to rush into it
>>
>> I disagree - the damage is accumulating as people start to build things
>> that depend on these facilities.
>>
>> At the very least, an immediate bugfix release with deprecations should
>> be released, so that people get informed of the mistake before the problem
>> gets worse.
>>
>> A mistake was made, and it's important to at least inform of that fact as
>> quickly as possible - whether we do or don't actually remove it down the
>> line at a later time... well, I'm not fond of things that light up red in
>> my IDE because of undefined classes, but lets at least deprecate so people
>> know it was a mistake?
>>
>
> I have been going through this thread and I want to agree with Rasmus
> here.
>
> As php-fig is making interfaces there is no need for test packages. And if
> needed this can be a util package. Better late than never ? Because things
> will get worse with more time being given.
>

I totally disagree that there is no need for test packages.

The specifications for the interfaces are generally quite strict, but,
particularly with versions that do not use PHP 7 (for scalar and return
type hints), PHP 7.1 (nullable and void types), or PHP 7.2 (object type
hint), having a test suite that can verify that the implementation conforms
to the specification is quite useful, particularly for consumers who want a
guarantee that swapping one implementation for another will result in the
same behavior. We've had a number of issues with PSR-7 over this, and the
test suite that Tobias Nyholm created helps implementors tremendously in
this regard.

That said, I tend to agree these should be _separate packages_. I disagree
with the urgency, but do agree it should be taken care of sooner rather
than later.

-- 
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_myXiXQCXvYccMyV96oNJO0B_sDChiHnx-Aar%2Be71QSD7rQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-19 @triggers tag

[Matthew Weier O'Phinney]

I'm against it, because it has a completely different connotation for me: I
would have assumed any code documented with it would _trigger an event_
using some sort of event dispatcher.

In terms of using it to document trigger_error calls, I'm in agreement with
Chuck: in most modern PHP I see, you raise exceptions instead. I only see
`trigger_error` used for deprecation notices generally, and those can be
documented with @deprecated instead.

On Wed, Dec 5, 2018 at 4:17 PM Chuck Burgess  wrote:

> I'm accustomed to seeing such old-style error behavior wrapped by
> exceptions as much as possible, so I'm -1 on the idea.
>
> Working Group / others, thoughts?
> CRB
> *about.me/ashnazg <http://about.me/ashnazg>*
>
>
> On Mon, Nov 26, 2018 at 5:00 AM Magnar Ovedal Myrtveit <
> mag...@myrtveit.com> wrote:
>
>> Would it be interesting to include a @triggers tag in PSR-19? This would
>> be used with code that may call trigger_error() or other code that may
>> trigger errors, such as filesize(), mime_content_type(), filemtime(),
>> md5_file(), pspell_new(), etc. (There are really many!)
>>
>> Examples would be:
>>
>> @triggers E_ERROR Some text explaining what might trigger the error.
>>
>> @triggers E_WARNING Some text explaining what might trigger the warning.
>>
>> --
>> 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/a044b2ab-a22a-4385-9a26-95c2fc1ac121%40googlegroups.com
>> <https://groups.google.com/d/msgid/php-fig/a044b2ab-a22a-4385-9a26-95c2fc1ac121%40googlegroups.com?utm_medium=email&utm_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/CANsgjnujHCAJd7rSvMYXX7az-8zM-%3DFJONz3JMJW44P3G5D0Pw%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CANsgjnujHCAJd7rSvMYXX7az-8zM-%3DFJONz3JMJW44P3G5D0Pw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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_myXK1W%3Dc4VteP4_KPUqOqGFdOs4pkZs%3DsyXt4mb3srjcqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: About the LateStreamInterface proposal

[Matthew Weier O'Phinney]

On Wed, Oct 31, 2018 at 5:01 AM Lcfvs  wrote:

> Hi all,
>
> I just sent a proposal to add an interface to describe a late stream,
> which doesn't requires an already opened resource.
>
> For the proposal, see https://github.com/php-fig/http-message/pull/82
>
> As said by Jean85:
>
> This is a completely non-trivial change to the spec, and also not an
>> errata. I would say that you should push for this change opening a
>> discussion on the PHP-FIG mailing list...
>>
>
> ... then I'm here. :D
>
> My motivation is about the
>
>- server limitations (max opened files)
>- performances in case of unused streams
>- the ability to get a stream of broken uploaded file
>- ...
>
> Indeed, it isn't an errata, I made it to avoid any breaking changes, it's
> why a new interface.
>
> What do you think about it?
>

I think it's quite interesting, but any substantive change - which includes
additions and removals — requires either errata or a new PSR. Generally
errata are reserved for changes to the existing interfaces and/or
narrative, while additions and removals require new PSRs.

Honestly, we need to likely update PSR-7 to PHP 7.1, to allow for scalar
and return type hints, which also requires a new PSR, and this would fit in
that nicely.

-- 
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_myXJj7QeeKnDGeJ0TtZzym%2B-ox9j606qQecYyAPdKiD_vQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

+1 from me.

On Sun, Oct 14, 2018, 9:46 AM 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/http-client.md
>
> - Metadocument:
> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-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/c905e09c-7181-4646-b33f-17dde2129815%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/CAJp_myXqN7m2gS_N-aR%2BAtiUpnuh-xLjddwCKXOYkNSBEc9X-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSSION] PSR-18 HTTP Client Acceptance Vote

[Matthew Weier O'Phinney]

I know for sure HTTPlug has been following the spec, and that has a whole
ecosystem of both first and third party adapters.

While the implementations should be provided/listed during review, my
understanding is that they should not be listed in the metadoc itself as
the implementation generally changes after acceptance. I know we did not
provide them in that location in either psr-15 or psr-17.

On Sun, Oct 14, 2018, 10:35 AM Michael Cullum  wrote:

> Hi,
>
> One of the core requirements for a specification to proceed from review
> and be fully accepted is the demonstration of multiple full
> implementations. No such implementations are mentioned in the metadoc or
> vote.
>
> Could references to some implementations please be provided (and they
> should also be added to the metadoc)?
>
> Thanks,
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+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/CAAqcDMh3OGsL8%3Dw4f-_Fmz-%3D2LTyeRZ6tJLptVdjiXH%3D52RzPA%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/CAJp_myUowFpcECWQwNHJAtP6bUo71jrdp1_JCQ8Qjgg7e7NH2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

Vote 1 (PHPDoc PSR-5): yes
Vote 2 (PHPDoc Tags PSR-19): yes

On Fri, Sep 14, 2018, 12:40 PM Michael Cullum  wrote:

> Hi all,
>
> PSR-5 has been quiet for a long time and it's recently been revived. The
> next step is having an entrance vote for the Core Committee. The purpose of
> an entrance vote is to agree it's a spec the FIG agrees should be worked on
> and start a working group, not to comment on any existing content of the
> specifications.
>
> The intention is to split what was PSR-5 into two separate PSRs, one for
> the PHPDoc format, and another to define a tag catalog. There will
> therefore be two votes. The rationale behind the splitting is to make it
> easier to add new tag dictionary PSRs in the future and also make PHPDoc
> more generic so it can be used for non-docblock standard such as
> Doctrine-style annotations.
>
> *Vote 1:*
> PHPDoc (PSR-5) -
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-meta.md
>
> *Vote 2:*
> PHPDoc Tags (would become PSR-19) -
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags-meta.md
>
> *Working group for both PSRs:*
> Editor: Chuck Burgess - PEAR
> Sponsor: Michael Cullum - PHP-FIG
> Alexey Gopachenko - PhpStorm
> Matthew Brown - Psalm
> Ondrej Mirtes - PHPStan
>
>
> Please when voting specify votes for both for example:
>
> Vote 1 (PHPDoc PSR-5): Yes
>> Vote 2 (PHPDoc Tags PSR-19): Yes
>
>
>
> *Please do not reply to this topic if you are not a CC member. *
>
> --
> 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/3cc1f7f8-97be-4c8d-9b29-353aa3365b35%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/CAJp_myXZMSPxDurBoi8WNfJ7eZMX8OqB7QLvjBV%2BQm7QaYr0sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14] Meeting Summary - 2018-08-15

[Matthew Weier O'Phinney]

On Tue, Aug 28, 2018 at 11:53 AM  wrote:

> Great, thanks for looking into it. I have one more suggestion, isn't it
> better to rename "getListenersForEvent" to "getEventListeners" ?
>

I personally prefer the current naming ("getListenersForEvent()"), as it
reads more like natural language. Additionally, `getEventListeners()`
doesn't have the same implication that we are retrieving only the listeners
for the specified event.


>
> On Tuesday, August 28, 2018 at 7:53:34 PM UTC+5, Larry Garfield wrote:
>>
>> Mainly because we didn't feel like typing a longer name, I think.
>> Nothing
>> more deep than that.
>>
>> That said, I checked and Symfony currently uses isPropagationStopped().
>> So we
>> may want to use the same to help with transitional code.  I'll add that
>> to the
>> agenda for our next call to discuss.  Thanks for the catch!
>>
>> --Larry Garfield
>>
>> On Friday, August 24, 2018 8:10:09 PM CDT desig...@gmail.com wrote:
>> > Sorry, correction, I meant ..
>> >
>> > "... so shouldn't "isPropagationStopped" make more sense here as the
>> > dispatcher would know that "event propagation" has been stopped by the
>> > previous listener?"
>> >
>> > On Saturday, August 25, 2018 at 6:06:31 AM UTC+5, desig...@gmail.com
>> wrote:
>> > > I'm very curious to know if there was a particular reason why
>> > > StoppableTaskInterface::isStopped() was not named
>> StoppableTaskInterface::
>> > > isPropagationStopped() ?
>> > >
>> > > The method description says "This will typically only be used by the
>> > > dispatcher to *determine if the previous listener halted
>> propagation*."
>> > > -- so shouldn't "isPropagationStopped" make more sense here as the
>> events
>> > > down the chain would know that "event propagation" has been stopped?
>> > >
>> > > On Tuesday, August 21, 2018 at 3:23:14 AM UTC+5, Larry Garfield
>> wrote:
>> > >> We had another good call with most of the Working Group present.
>> This
>> > >> time we
>> > >> went over several trial implementations that various Working Group
>> > >> members
>> > >> have built, to varying levels of completeness.  They're available
>> here
>> > >> (although their workingness at any given moment is not guaranteed,
>> as the
>> > >> spec
>> > >> evolves):
>> > >>
>> > >> Larry: https://github.com/Crell/Tukio
>> > >> Benni: https://github.com/bmack/kart
>> > >> Cees-Jan: https://github.com/wyrihaximus/php-broadcast
>> > >> Matthew: https://github.com/phly/phly-event-dispatcher
>> > >>
>> > >> On the whole we're pretty happy with where things are, although we
>> did
>> > >> come up
>> > >> with a number of additional spec tweeks to make.  The biggest is
>> changing
>> > >> the
>> > >> namespace of the package to Psr\EventDispatcher (rather than
>> Psr\Event
>> > >> \Dispatcher).  We're going to continue to do another round of
>> > >> implementing; in
>> > >> particular, Liz Smith is working on an event driven CLI app and
>> Cees-Jan
>> > >> has
>> > >> agreed to try a Promise-as-Event implementation to make sure it
>> works.
>> > >>
>> > >>  (It
>> > >>
>> > >> should, but better to actually do it.)
>> > >>
>> > >> We've also started building a util library to go along with the
>> spec,
>> > >> which is
>> > >> available here:
>> > >>
>> > >> https://github.com/php-fig/event-dispatcher-util
>> > >>
>> > >> Open questions are mostly around error handling minutia.  The big
>> one is
>> > >> whether it's appropriate, inappropriate, or required to have an
>> > >> ErrorEvent
>> > >> that is also itself an Exception, and thus can be thrown.
>> > >>
>> > >> For those following along at home, the latest code for the spec
>> > >> interfaces is
>> > >> here:
>> > >>
>> > >> https://github.com/php-fig/event-dispatcher
>> > >>
>> > >> And you should use the 0.4.0 tag for 

Re: [REVIEW] PSR-18 HTTP-Client

[Matthew Weier O'Phinney]

d 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/3e454eb9-5088-40fb-b280-1d82725b512c%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/C5077FA0-7DF9-4763-816D-1BB6ACAF4684%40gmail.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/CAGOJM6KTyb3pYaA0LizsFWfrb-zgASAk0kPDJ_b-3%3DoveEdYjQ%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/41A79104-E56E-4E11-9691-E3D342A9199E%40gmail.com
>> <https://groups.google.com/d/msgid/php-fig/41A79104-E56E-4E11-9691-E3D342A9199E%40gmail.com?utm_medium=email&utm_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/CAFojS1tOnNsEp6JajY-mEcef4TmWP0zRDnWHmoYYkMWj5eY5NQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAFojS1tOnNsEp6JajY-mEcef4TmWP0zRDnWHmoYYkMWj5eY5NQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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_myWFQ62Gg2pZWZua3eVX_-Oj9tyU7wjv%2BxFKOqprTVvjJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14] Alpha 1

[Matthew Weier O'Phinney]

Just as an FYI: This discussion is essentially moot with recent revisions
of the spec.

We are not defining listener attachment as part of the spec at this time,
as there are SO many ways to accomplish it. Instead, we are defining a
`ListenerProviderInterface`, with the single method
`getListenersForEvent(EventInterface $event) : iterable`. It is then up to
implementations to determine how to populate the set of listeners.

Why are we not defining attachment? Because there's no one way to define it:

- You could do reflection on the callable to determine what the argument to
it is in order to determine what it can listen to.
- You could accept an event class name as an argument, along with the
listener.
- You could accept an event INSTANCE as an argument, along with the
listener.
- You might want to attach listeners using a priority integer, to allow
ordering listeners (useful only for the `TaskProcessorInterface`).
- You might want to allow operations such as "first", "last", "before",
"after", etc. as mechanisms for ordering listeners (again, only for use
with the `TaskProcessorInterface`).
- You might want to allow lazy-loading (i.e., instead of passing a listener
callable, you pass a service name and/or a method on that service to call).

There are a ton of options, and we cannot feasibly cover them all in the
spec. We CAN cover how to retrieve listeners for the event being
dispatched, however. We will LIKELY provide interfaces and/or
implementations of providers with different attachment methods in our util
package, but these are not and will not be covered by the specification.

Finally, we do not allow arbitrary string event names nor do we define
something like a `getName()` method on events. The fully-qualified class
name of the event type is definitely enough here, and there are plenty of
existing systems out there that demonstrate its effectiveness (e.g.,
Composer's internal events!). Contrary to your last assertion, `::class`
does NOT require an instance to access; you can access it using the FQCN:
`Foo\Bar\BazEvent::class`. When the class is imported into the current
file, then this becomes even more succinct: `BazEvent::class`. If you HAVE
an instance already, great — but for the common case of attaching
listeners, you can use one of these FQCN notations instead.

Yes, it DOES require a class is defined, which eliminates the possibility
of anonymous class implementations of events... UNLESS they implement
specific interfaces. In that situation, your listeners can attach using the
interface name (which can ALSO be identified by `::class` notation).

On Mon, Aug 20, 2018 at 10:38 AM  wrote:

> To use `::class`, the event object must have already been created. To that
> I wonder if, when attaching events to listeners by name, should this really
> be a hard requirement (i.e. the event object being created)?
>
> On Monday, August 20, 2018 at 8:27:10 PM UTC+5, Woody Gilk wrote:
>>
>> On Mon, Aug 20, 2018 at 10:16 AM  wrote:
>> >
>> > Right. In that case, the string $eventName would have to be a fully
>> qualified event class name (including the namespace) for the emitter to
>> pick it up correctly. Isn't that a bit impractical? Or should we just be
>> looking at the event name and stripping off the namespace (in emitter) like
>> maybe by doing something like:
>> >
>> > $eventName = end(explode('\\', get_class($command)));
>>
>> I don't think it is impractical at all. Mapping by full class name is
>> very easy with `Foo::class` and FQCN prevents duplicate errors, eg:
>>
>> Acme\Domain\Task\UpdatedEvent
>> Acme\Domain\User\UpdatedEvent
>>
>> --
>> Woody Gilk
>> https://shadowhand.me
>>
> --
> 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/8158bd9b-3458-4f55-94e9-d489f19fe87e%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/8158bd9b-3458-4f55-94e9-d489f19fe87e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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_myWqtUv2XNZDimWWLG9upt7hGCcgOmDya52Rympub31QxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][WG] Readiness vote for PSR-18

[Matthew Weier O'Phinney]

+1 from me.

On Tue, Aug 14, 2018 at 9:43 AM Sara Golemon  wrote:

> The PSR-18 working group is excited to move our draft into the review
> phase.  To that end, we are holding a public vote on draft readiness.
>
> 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.
> A -1 means that you think the working group should discuss this more.
> A 0 vote indicates you are explicitly abstaining.
>
> As this is a readiness vote, quorum will be 50% and a majority of at least
> 2/3 is required for passage.
>
> --
> The current working group for PSR-18 is as follows:
>
> Editor:
> Tobias Nyholm
>
> Sponsor:
> Sara Golemon
>
> Members:
> Simon Asika (Windwalker)
> David Buchmann (HTTPlug)
> David De Boer (HTTPlug)
> Jermey Lindstrom (Guzzle)
> Christian Lück (Buzz react)
> Matthew Weier O'Phinney (Zend)
> Mark Sagi-Kazar (Guzzle)
> Joel Wurtz (HTTPlug)
>
> Please do not reply to this thread unless your name is listed above.
>
> Thanks,
> -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/51be965e-5ed9-4c24-ab6d-2fd8ab64327b%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/51be965e-5ed9-4c24-ab6d-2fd8ab64327b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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_myWh%3DT8YDieGHaCPVwv1gE-VHW5Or0JeMLLUN2CC2GsLeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Secretary Elections - Voting is Now!

[Matthew Weier O'Phinney]

Voting as a CC member:

- Ian Littman
- Alessandro Lai
- Daniyal Hamid

On Sat, Aug 4, 2018 at 11:36 AM Dead Lugosi 
wrote:

> Ohai FIG Humans,
>
> It's time to cast your votes for new Secretary terms
> <https://www.php-fig.org/bylaws/mission-and-structure/#secretaries>!
>
> We have two openings we are voting on:
>
>- The Secretary term currently filled by Alessandro Lai is ending and
>the new term up for election will run until August 2020.
>- The Secretary seat recently vacated by Mark Railton is up for
>election and that term will run until May 2019.
>
> Our candidates are:
>
>- Alessandro Lai
>- Ian Littman
>- Daniyal Hamid
>
> *Any Project Representative or Core Committee member is eligible to vote
> on Secretary candidates.*
>
> Because we are voting on more than one open position, we will consider the
> candidate receiving the most votes to have been elected for the longer of
> the two terms.
>
> The votes will be tallied using the Single Transferrable Vote
> <https://en.wikipedia.org/wiki/Single_transferable_vote> style, so
> provide your vote with a reply to this thread, ranking candidates in the
> order of your preference.
>
> If you have any questions for the candidates before voting, please feel
> free to post those to this thread so that other voters may also see any
> answers the candidates provide.
>
> *Voting for the Secretary Elections will END on August 18th. Get your
> votes in now!*
>
> Thank you for your input and participation in this important process.
>
> Best,
>
> Director of Cat Herding
>
> --
> 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/f65f6963-552d-4d15-b20a-fafa23e326ef%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/f65f6963-552d-4d15-b20a-fafa23e326ef%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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_myW-3Czguypg0aHyL1i6spmqhZ6mM8k4r%2B9F2JpxNzQZPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

+1 from me.
On Wed, May 23, 2018 at 12:33 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> After some lengthy debate this past week, we've reverted the changes to
the
> spec that required inheritance in factories for classes that have
> collaborators. We feel those can be achieved via "union type" interfaces
or
> a "SuperFactory" (combining all interfaces into a single instance) that we
> can ship in a `-util` package. Either way, it is out of scope for the spec
> itself.

> As such, Woody has delegated to me once again 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 06 June 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
> mweierophin...@gmail.com
> https://mwop.net/



-- 
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_myWQVNYez7%2B5mCmha%3D_0yDngK252mEvD7Z10PY-d%2BcCMcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.