Re: [PSR-11] Review: remove the sentence about optional "get" parameters

> > So just to get this straight: we remove the sentence (because it sounds > weird to have it in a standard), but we agree that it's still completely > fine if implementations have extra *optional* parameters right? If it were completely fine, we wouldn't remove the sentence, no? Optional

Re: [PSR-11] Review: remove the sentence about optional "get" parameters

Hi Niklas, I think there is a misunderstanding. - if you use the interface, then you use the parameters defined in that interface => so yes, you should NOT pass extra parameters (we agree on that, that doesn't make sense) - if you don't use the interface but the implementation directly, then

Re: [PSR-11] Characters allowed in service IDs

I agree with Matthieu. Specifying what legal characters are supported definitely belongs to another PSR (the one where we put things into the container). I'll propose a PR in container-interop/service-provider to define precisely the

Re: [PSR-11] Exceptions

@Larry: the DependencyNotFoundException was discussed quite recently. Here is the relevant link explaining the story behind it and why there is no DependencyNotFoundException: https://github.com/php-fig/fig-standards/pull/810 Le mercredi 2 novembre 2016 22:53:13 UTC+1, Matthieu Napoli a écrit

Re: [PSR-11] Review: should the container ALWAYS return the same instance?

> The typical use case for ContainerInterface is to allow a consumer (like a router) to be "container agnostic". I completely agree. I can't think of a use case where a router would depend on having either shared instances or exclusive instances of a controller, so I'll change this example a

Re: [PSR-15] Falsehoods About The Client-side

On Thu, Nov 3, 2016 at 2:47 AM, Matthieu Napoli wrote: > Also that would maybe mean we can get rid of the dual > "MiddlewareInterface" and "ServerMiddlewareInterface"? It would indeed, which would solve one of the most contentious points about PSR-15. Unlikely that I will

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

Hi, The goal of the php-fig/log repository is to provide interfaces and more globally a standard for logging. You are pointing out an implementation issue. The code you saw in the README is only an example. A real example would be like

Re: [PSR-15] Falsehoods About The Client-side

Hi Matthieu, calling the root middleware seem to be a valid use case for server middlewares too: If a middleware have to create (virgin) Requests, then calling the root middleware makes a lot more sense than calling the next middleware. May you give me a hint where Joel mentioned this? – I

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

Thank your for this fast answer. As i wrote i am aware that this was just an example. I am just wondering when things going towards standards then why is NULL not considered to be a standard value. NULL is wanted sometimes to express that someting is optional. Am Donnerstag, 3. November 2016

Re: [PSR-15] Falsehoods About The Client-side

Ah sorry it was a discussion IRL :) Calling the root middleware for the server apps is a much less widespread use case AFAIK. In existing implementations and de-facto standards (HttpKernelInterface and "PSR-7 middlewares") there is no such thing, so (IMO) it wouldn't make sense to create such a

Re: [PSR-11] Characters allowed in service IDs

I disagree for exactly that reason. :-) If the goal is interoperability, then containers need to have at least a common baseline of what they should allow. It's essentially an additional layer of type checking beyond just "string". That doesn't mean it has to specify a dot-delimited format,

Re: [PSR-11] Exceptions

From moufmouf in that thread: " The logic behind this is that if a user is calling the get method on 'foo' and 'foo' does not exist, it is very different from the user calling get on 'foo' and the 'foo' service has a missing dependency. In one case, maybe the user screwed up something (i.e.

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

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

Re: [PSR-11] Characters allowed in service IDs

> However, if I'm trying to connect two containers (for delegation), and one uses a pizza emoji and the other only allows ASCII characters, then they're not actually compatible. The latter should break when setting the entries, not when fetching them. Restricting what entries can be fetched

Re: [PSR-15] Falsehoods About The Client-side

Hi, David and Matthieu already give my point of view, however there is still some things to consider: At HttpPlug we wrote a lot of client side Middleware from what we have done we organise them in 3 categories (cf http://docs.php-http.org/en/latest/plugins/introduction.html part about

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

Just a few of clarifications: - You can nominate multiple people, in fact, this is to be encouraged so we have a good number of CC candidates (15-20). - You can nominate yourself if you are a project representative (if you wish) - Only project representatives and Secretaries can nominate people

Re: [CC Nomination] Jason Coward

Thank you Korvin! You saved me from nominating myself which I did not want to do. ;) I accept the nomination and look forward to this new chapter of the PHP FIG unfolding. Sincerely, Jason Korvin Szanto November 3, 2016 at 11:46 AM Hi All, Yesterday Jason

Re: [PSR-11] Exceptions

> but because it doesn't know that it's a child it just throws "I don't have it", which gets thrown all the way up to the initial caller, who goes "wait, wat?" It would be considered as bugged PSR-11 implementation. > then it needs to wrap that inner Not-Found with... something. That

Re: [PSR-11] Characters allowed in service IDs

On Thu, Nov 3, 2016 at 9:41 AM, Larry Garfield wrote: > I disagree for exactly that reason. :-) > > If the goal is interoperability, then containers need to have at least a > common baseline of what they should allow. It's essentially an additional > layer of type

[CC][Nomination] Graham Daniels

I hereby nominate Graham Daniels for a position on the Core Committee. Graham has excellent development skills, as evidenced by his activity in the League of Extraordinary Packages, as well as his work at refinery29. He speaks often at conferences on development topics, but, also, and arguably