[CC][Nomination] Graham Daniels

Thank you very much. I gladly accept the nomination. -- Graham -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@goog

[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 mor

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 checking beyond just "string".

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 somethi

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 ap

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 M

[CC Nomination] Jason Coward

Hi All, Yesterday Jason appealed to the group [1] requesting to be nominated to run for the core committee. Now I don't personally know Jason, but I also don't have any reasons why he should not be nominated. Instead of hoping someone else will do it, I think it's best to get it done now and nomina

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 orde

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 do

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 ju

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

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

Suggestion: Make no comment in the spec itself, but note in the metadoc that "some existing implementations have extra optional parameters; that's technically legal for backward compatibility but discouraged". So that way Symfony's DIC, for instance, can remain compatible but anyone writing 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-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 bi

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

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 can'

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 https://github.com/Seldaek/monolog/blob/7ce63f964426a57b6

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

Can you guys please answer this question to me http://stackoverflow.com/questions/40401259/psr-log-why-no-null-default-value-for-loggerawareinterface-and-loggerawaretraiace and LoggerAwareTrait Thank you -- You received this message because you are subscribed to the Google Groups "PHP Framew

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 have time to work on

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

If one relies on passing other parameters to the container on their consumer implementation, then they're not coding to a generic interface, but to a specific container implementation. So, this PSR has no business saying what he can or can't do. Maybe we could specify that if implementations al

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 l

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] 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 all

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] 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 pa

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

Definitely agree with making PSR-15 about server side middlewares only. Joel mentioned several reasons why client-side middlewares needed something different (e.g. the ability to reference the root middleware, for example to follow a redirect through the whole stack again). Also that would mayb