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

[Matthieu Napoli]

+1

Le mardi 15 mai 2018 18:06:02 UTC+2, Matthew Weier O'Phinney a écrit :
>
> Woody has delegated to me to open a vote to enter the REVIEW period for 
> PSR-17. This vote is open only to PSR-17 Working Group members; at this 
> time, that means: 
>
> - Woody Gilk (Editor) 
> - myself (Sponsor) 
> - Stefano Torresi 
> - Matthieu Napoli 
> - Korvin Szanto 
> - Glenn Eggleton 
> - Oscar Otero 
> - Tobias Nyholm 
>
> The by-laws do not stipulate a time-frame for how long the vote must 
> run, though 2 weeks is the standard period. As such, the vote will run 
> until 23:59:59 on 29 May 2018, or until all members have responded. Once 
> the vote is closed, I 
> will post the results, and indicate next steps for the proposal. 
>
> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS 
> LISTED ABOVE. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@gmail.com  
> https://mwop.net/ 
>

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

Re: Service provider PSR: discussing the scope

[Matthieu Napoli]

>
> Using the container for configuration is not (imho) the purpose of 
> containers and makes it harder to standardize on using FQCN for container 
> identifiers.


I don't think it's limited to configuration. You'd have the same 
(non-)issue with config-less containers.

Matthieu
 

> On Sat, Mar 3, 2018, 15:18 Oscar Otero <oscar...@gmail.com > 
> wrote:
>
>> To me, the problem with these proposals is they have different 
>> responsabilities in the same class. A ServiceProvider implementation 
>> includes the callables to create instances of different services, defines 
>> the key used to store each of these services and even include two methods: 
>> one to get factories and other for extensions, so in many times you have to 
>> create a method returning an empty array (see 
>> https://github.com/container-interop/service-provider/issues/43), 
>> (Interface segregation principle).
>>
>> I proposed a different approach (
>> https://github.com/container-interop/service-provider/issues/45) 
>> consisting in creating a factory for each service. The proposal is just a 
>> sketch to illustrate the main concept (each object has just one 
>> responsabiity: create a service) and surely can be improved.
>>
>>
>>
>> El 3 mar 2018, a las 14:07, David Négrier <david@gmail.com 
>> > escribió:
>>
>> To build upon Larry's answer, the container does not only contains 
>> services. It knows how to build them.
>>
>> If we ended up "setting" in a container every service, well first... we 
>> could use arrays instead of containers :) and then, the performance of the 
>> container would degrade proportionally to the number of entries in the 
>> container. You would have to instantiate and store every service on every 
>> request, even if the service does not end up being called. So basically, 
>> the bigest your application, the slowest.
>>
>> This is why both proposals carefully avoid the use of a "set" method.
>>
>> ++
>> David.
>>
>>
>> Le vendredi 2 mars 2018 23:02:49 UTC+1, Larry Garfield a écrit :
>>>
>>> The reason a simple set() won't work is that the "thing" put into the 
>>> container is generally not a value but instructions for how to produce a 
>>> value 
>>> on-demand, and the value is typically a service object.  How to encode 
>>> "here's 
>>> how to build the thing" is the main question to answer. 
>>>
>>> --Larry Garfield 
>>>
>>> On Friday, March 2, 2018 1:18:32 PM CST David Lundgren wrote: 
>>> > If the problem to solve is "what's a common way to put things in a 
>>> > container?" wouldn't the simplest solution be a `set($id, $value)` 
>>> method 
>>> > on the container? 
>>> > 
>>> > Most container implementations already have a method of this sort. 
>>> While a 
>>> > few have shared/concrete/protected concepts baked in, they could make 
>>> > separate methods for changing it  based on the $id. 
>>> > 
>>> > Dave 
>>> > 
>>> > On Thursday, March 1, 2018 at 11:16:29 AM UTC-6, David Négrier wrote: 
>>> > > Hey list, 
>>> > > 
>>> > > We are still in the process of forming a working group regarding a 
>>> Service 
>>> > > provider PSR. 
>>> > > 
>>> > > I've had the chance to speak about this with several Symfony 
>>> contributors, 
>>> > > and while discussing about this idea, Nicolas Grekas 
>>> > > <https://github.com/nicolas-grekas/> (from Symfony) came up with an 
>>> > > alternative proposal. It's about having many containers working 
>>> together, 
>>> > > with a slightly different scope. First of all, I'd like to thank 
>>> Nicolas 
>>> > > for the time he is investing in researching this issue, and for all 
>>> the 
>>> > > feedback. We talked about his idea with Matthieu Napoli 
>>> > > <https://github.com/mnapoli/> and Larry Garfield 
>>> > > <https://github.com/crell> at the Paris ForumPHP in November. I'm 
>>> now 
>>> > > sharing this conversation with you. 
>>> > > 
>>> > > I put this in a blog article that you can find here: 
>>> > >
>>> https://thecodingmachine.io/psr-11-scope-of-universal-service-providers 
>>> > > 
>>> > > I'm reposting the content of the 

Re: PSR for HTTP clients

[Matthieu Napoli]

I have to agree with Larry, having the behavior of a standard depend on 
some configuration is risky. If the goal of the PSR is to be used by 
libraries or frameworks (not end users) then it's fine to force a choice 
IMO.

I have minor comments about the proposal, maybe it's too early to get into 
details and create a proper thread but I would suggest making the 
exceptions clearer:

 * Exception for when a request failed. * Examples: *  - Request is invalid 
(eg. method is missing) *  - Runtime request errors (like the body stream 
is not seekable)interface RequestException extends Exception


How about InvalidRequestException? (I would suggest InvalidRequest but it 
would be a waste of time :p)
We need to make it clear that the HTTP request did not fail, it's the 
Request object that was invalid.

 * Thrown when the request cannot be completed because of network issues. * 
There is no response object as this exception is thrown when no response has 
been received. * Example: the target host name can not be resolved or the 
connection failed.interface NetworkException extends Exception


NetworkErrorException? OK maybe this one is too much (NetworkError would be 
better but…)

And as said above HttpException should probably be removed entirely?

Matthieu

Le mardi 11 juillet 2017 18:33:15 UTC+2, Larry Garfield a écrit :
>
> I'm inclined to agree here.  Error handling that may change based on some 
> config not available to me in local scope, like PDO does, is a design flaw, 
> as I then have to account for both possible error flows.
>
> I could be argued in favor of exceptions always or exceptions never (I'm 
> leaning exceptions on all 4xx/xx right now, but could be convinced 
> otherwise), but "exceptions sometimes" doesn't seem like a good choice.
>
> That said, that's a detail that doesn't block officially forming the WG; 
> I'm +1 on approving this as a WG to hash out exactly those sorts of details.
>
> --Larry Garfield
>
> On 07/11/2017 11:12 AM, Josh Di Fabio wrote:
>
> Right, I see; I saw the *HttpException* class but I missed that it *MUST 
> NOT be thrown when using the client's default configuration.* 
>
> Having said that, I think the fact that the behaviour of *sendRequest()* 
> varies 
> based on some configuration which isn't available via the interface is 
> actually worse than always throwing. Given that most people will be 
> injecting their *HttpClient* instance into other objects and probably 
> passing one instance around to multiple classes, the code which is calling 
> *sendRequest()* won't generally have visibility over how the client is 
> configured, so we'll have to be super defensive when calling the client to 
> be sure we handle 4xx and 5xx responses correctly: 
>
> try {
> $rep = $client->sendRequest($req);
> } catch (HttpException $e) {
> $rep = $e->getResponse();
> }
>
> It should either always throw or never throw. The behaviour of redirects 
> should also be consistent or configurable via the interface or else 
> autowiring will be useless for instances of *HttpClient*.
>
> On Tue, Jul 11, 2017 at 4:51 PM  wrote:
>
>> I think I've been unclear or you misread something. 
>> A HTTP client MUST NOT throw exceptions for any response. 
>>
>> So I very much agree with you. 
>>
>>
>> On 11 Jul 2017, at 17:45, Josh Di Fabio  
>> wrote:
>>
>> This looks pretty good, but I don't like exceptions for 4xx and 5xx 
>> responses, which smells of exceptions for flow control. Within the context 
>> of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather, 
>> whether a certain response status is considered exceptional depends on the 
>> context of the caller. For example, in many contexts a 3xx response would 
>> be unexpected but a 404 response would not. Instead of throwing, the client 
>> should simply return the response.
>>
>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai > > wrote:
>>
>>> Very good suggestions. 
>>> Also, it's very pleasant to see a PSR pushed this way and backed from 
>>> the start by a working lib and all the interestend players. Really good job!
>>>
>>>
>>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha 
>>> scritto:
>>>
 On 07/07/2017 12:20 PM, Tobias Nyholm wrote:

 Excellent questions. Thank you.  

 The buy-in would be the same for every PSR, wouldn't it? Libraries do 
 not want to depend on an implementation or provide an implementation 
 themselves. They want the user to decide if a highly flexible client 
 (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
 https://github.com/joelwurtz/http-client-benchmark). Also, as you 
 probably noticed, there are representatives from all PSR7 compliant HTTP 
 clients in the workgroup. 


 That last point was what I was getting at, thank you.  By buy-in, I 
 mean "do we have an indication that the major HTTP clients 

Re: Minimal HTTP middleware

[Matthieu Napoli]

Hi Michael, those are interesting points, my answers inline:

On Sunday 21 may 2017 10:43:57 UTC+2, Michael Mayer wrote :
>
>
> On Saturday, May 20, 2017 at 10:33:33 PM UTC+2, Matthieu Napoli wrote: 
>
>> Rasmus:
>>
>> I can see the handler-interface having 3 uses in the context of PSR-15:
>>> …
>>> 3. As type-hint for the "final" handler supported by many dispatchers.
>>
>> 3. I agree this is a bit of an ugly detail and it would be better if we 
>> could do without, but honestly this is just a detail, and it works, and 
>> it's not really a practical problem, I don't see how a PSR would matter here
>>
>
> That PSR would also allow interop of routers, controllers and final 
> handlers, and indeed solve practical problems, e.g. if you use it with your 
> pipe function:
>
> // diff in pseudo code:
> - function pipe(MiddlewareOrHandler[] stack) : Middleware {}
> + function pipe(Middleware[] stack, Handler $final) : Handler {}
> - function router(array routes) : Middleware {}
> + function router(array routes) : Handler {}
>
> Thus you do not need to fabricate handlers like the one at your 
> Router::dispatch 
> <https://github.com/stratifyphp/router/blob/779a77b6b8078fa3cb2fe86a3361c43b06df94e0/src/Router.php#L83-L85>,
>  and 
> the code of your example becomes bit more explicit:
>
> […]
>
> As you can see, there is no essential difference for the end user setup. 
> Although, we do not need to create those meaningless $next delegates: the 
> prefix and router functions return them.
>

That's an interesting solution and yes it makes sense. However it is more 
limiting than the solution where *everything is a middleware*. When you 
have middlewares and handlers you can't add a handler into a middleware 
pipe. You are forced to put it as the "last handler". This is less 
interoperable.

You cannot, for example, do this:

$application = pipe([
ErrorHandlerMiddleware::class,

// Resolve the controller and store it in the request
router([
'/' => /* controller */,
'/article/{id}' => /* controller */,
]),

Firewall::class,
ControllerDispatcher::class, // actually invoke the controller
]); 

In the example above the controller dispatcher (or "invoker") is extracted 
from the router so that we can put middlewares in-between them, for example 
here to check permissions to access to each route.

Yes, the dispatcher could be the final handler, but my point is that the 
separation between handlers and middlewares is fuzzy, there are plenty of 
scenarios where a handler could actually be used as a middleware, so most 
handlers might actually need to implement both interfaces.

To sum up more clearly:

- MiddlewareInterface: standard for interoperability
- HandlerInterface: standard just because "this is a common signature"

IMO the middleware interface is the key for interoperability.

 

>
> And yes the router will be invoked with a $next, but IMO that's a good 
>> thing: the router can call $next if the URL doesn't match any route 
>> <https://github.com/stratifyphp/router/blob/master/src/Router.php#L58-L63>. 
>> That allows, for example, to use several routers in a single pipe (e.g. if 
>> you have modules).
>>
>
> I disagree, that's not a good thing, this means $next would be used 
> differently by different middlewares:
> For example for your HttpAuthenticationMiddleware, calling $next means: 
> *everything 
> is fine*; lets carry out the real task and if that fails I will try to 
> handle that.
> For the router you're suggesting, calling $next means: *something went 
> wrong*; lets delegate the task to someone else and if that fails I do not 
> care.
>

Nope that's not what I'm saying. Here is an example to illustrate:

$application = pipe([
// Module
Blog::class,

// Routes of my application
router([
'/' => /* controller */,
'/article/{id}' => /* controller */,
]),
]); 

The "Blog" module could be a router (or a pipe, we don't really care) that 
provides "blog" routes. Imagine also all the modules/bundles that provide 
authentication routes (login/logout, OAuth), asset routes (Glide comes to 
mind), whole application parts (e.g. SonataAdminBundle), etc. The router of 
that module simply calls $next if no route matched.

Calling next means: I delegate handling the request.

It doesn't intrinsically mean something went right (authentication) or 
wrong (404 not found).


And by the way this is a bit what Slim and IIRC Zend Expressive do: route 
>> handlers can be controllers or can be pipes, that's how you can add "route 
>> middlewares" (I hope I'm not wrong here).
>>
>
> Slim controller actions 
> <https://www

Re: Minimal HTTP middleware

[Matthieu Napoli]

Hi everyone,

I've been following that discussion, I just want to react to a few things:

Woody:

This works perfectly well for simple systems and not so well for more 
> complex systems. For instance, if we have a complex application where there 
> is a "user" part and an "admin" part, the admin part needs a different 
> sequence: […] Instead, the middleware becomes more of a tree structure


I agree with that, that's the approach I've been following. However I 
disagree with you that's it's sort-of incompatible with the current 
middlewares. Here is an example of an application that can be built with 
middlewares (link to the gist 
):

$application = pipe([
ErrorHandlerMiddleware::class,
ForceHttpsMiddleware::class,

prefix([

// API with authentication
'/api/' => pipe([
HttpAuthenticationMiddleware::class,
router([
'/api/articles' => /* controller */,
'/api/articles/{id}' => /* controller */,
]),
]),

// Public website
'/' => pipe([
MaintenanceModeMiddleware::class,
SessionMiddleware::class,
DebugBarMiddleware::class,
router([
'/' => /* controller */,
'/article/{id}' => /* controller */,
]),
]),

]),
]); 

Don't mind the functions (pipe(), router(), …) these are just helpers to 
instantiate Pipe/Router/PrefixRouter middlewares.
But as you can see this is a tree, and the middleware approach with $next 
doesn't restricts us to "just a list of middlewares". A router for example 
creates a node with several sub-items. And yes the router will be invoked 
with a $next, but IMO that's a good thing: the router can call $next if the 
URL doesn't match any route 
. 
That allows, for example, to use several routers in a single pipe (e.g. if 
you have modules).
Also a quick note: if you want to point out that a router should not 
dispatch, fine, just add the router as a middleware higher up the pipe and 
replace "router" with dispatcher. The example of the tree above still 
stands.

And by the way this is a bit what Slim and IIRC Zend Expressive do: route 
handlers can be controllers or can be pipes, that's how you can add "route 
middlewares" (I hope I'm not wrong here).

My conclusion is that *the current signature is very simple and powerful*, 
are the "cons" are only little details, so we should definitely stay with 
that interface and not the handler interface or some other limited 
interface like what you suggest: "$request = $foo->modify($request);".
The middleware interface is simple and extremely powerful, if we want to 
cover all scenarios with more specific interfaces we would need a ton of 
different interfaces, and it would be really hard to connect them all 
together.

Rasmus:

I can see the handler-interface having 3 uses in the context of PSR-15:
> 1. As the common interface of middleware dispatchers.
> 2. As the type-hint on delegates.
> 3. As type-hint for the "final" handler supported by many dispatchers.


Agreed, but:

1. those dispatchers still need to implement the middleware interface 
because, thanks to that interface, they can be composed with other 
middlewares (inserted into a pipe or router, example below) -> the 
dispatcher signature (without $next) is useful *for end users, not 
interoperability *(the $next parameter is the key for 
composability/interoperability), as such it's not a matter for the PHP-FIG 
IMO.
$application = prefix([
'/api/' => $expressiveApplication, // The API is done with Zend 
Expressive
'/' => $slimApplication,   // The website is done with Slim
]);

2. yes but delegates are just a tool/implementation detail to connect 
middlewares together, so I don't think that pushes for a whole PSR for that 
interface

3. I agree this is a bit of an ugly detail and it would be better if we 
could do without, but honestly this is just a detail, and it works, and 
it's not really a practical problem, I don't see how a PSR would matter here

As such, I'm not really against a HandlerInterface as a separate PSR but I 
don't think it's worth it. Also if packages start shipping "handlers" that 
are not middlewares, then they cannot be put inside middleware 
architectures and there goes the whole plan of interoperability.

I hope I'm making sense :)

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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 

Re: Minimal HTTP middleware

[Matthieu Napoli]

>
> > This is Symfony's HttpKernelInterface and StackPHP and it has already 
> been discussed at length
>
> Same principle, yes, but what I recall being discussed at length was the 
> lambda-style vs double-pass aspect, which seems unrelated to this 
> discussion.
>
> I found one or two older threads on this subject, here's one:
>
> https://groups.google.com/d/msg/php-fig/Ew36Ng5EwXE/52dAzZAbAQAJ
>
> The discussion quickly turns to the other, at the time dominant subject 
> though.
>

OK I've started to re-read the mega-thread 
(https://groups.google.com/forum/#!topic/php-fig/vTtGxdIuBX8%5B101-125%5D - 
7 pages long) but most of the debate was indeed about 
lambda-style/double-pass, and I'm clearly not masochistic enough to read 
all of it again ^^

So yes maybe we should discuss that (to me it feels like "again" but maybe 
that's just me).
 

> > I'm not sure why we are starting it all again?
>
> Are you're saying all of the concerns I described here have been discussed 
> and are all invalid?
>
> According to the PSR-15 meta:
>
> - "There are currently two common approaches to server middleware that use 
> HTTP Messages", single-pass and double-pass.
>
> - There's no mention of the fact that HttpKernelInterface doesn't have 
> the delegate in the interface.
>
> - The section on "Delegate Design" talks about the design of that 
> interface, but doesn't say why it exists in the first place.
>
> I recall there being lengthy discussions about how to name and describe 
> the delegate interface, but skimming back through the discussion threads 
> that are listed in the meta, it seems that the discussions all start from 
> the assumption that a middleware interface has the delegate argument.
>

So yes even if it was discussed or not, the fact that it lacks from the 
metadocument is a sign there is something to improve here.

My 2 cents about the Stack approach:

- AFAIK it didn't work. And it was not tried in some weekend project: it 
was built on Symfony's interfaces, so pretty solid stuff and it got a good 
chance for success. On the other hand PSR-7 middlewares were incompatible 
with most of the existing architectures at the time (incompatible with 
Symfony for example) and without a standard interface (rather a "callable" 
convention) and it worked out! So to me that's a clear sign.
- it's harder to compose middlewares because they are all nested: the 
"pipe" pattern was a huge help IMO in spreading the concept
- it's harder to write reusable middlewares because you need to standardize 
the constructor (see the Stack "convention" about the constructor which is 
less than ideal)
- it's harder to wire in DI containers
- lazy middlewares are doable but not as easy

That's all I have on my mind right now. And we may or may not have 
discussed it before, but the PHP community has already tried it. That kind 
of middleware has existed for a long time, and right now what works and 
what's spreading is not that kind of middlewares. I believe that's because 
of good reasons and we should not ignore that and start all over again.

Matthieu

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b8317921-172a-476c-9df7-5b47e1f089da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Matthieu Napoli]

Hi,

This is Symfony's HttpKernelInterface and StackPHP and it has already been 
discussed at length, I'm not sure why we are starting it all again?

Matthieu

Le vendredi 21 avril 2017 17:42:11 UTC+2, Rasmus Schultz a écrit :
>
> I hate to do this at a time when the middleware PSR is probably close to 
> finished, but since this occurred to me, I can't shake the thought, and so 
> I have to bring this up, so that at least others are aware and informed 
> about this option with regards to middleware.
>
> I think I saw some framework in Dart doing this a couple of months ago, 
> and I instinctually rejected the idea, because (A) I have a substantial 
> time investment in PSR-15, and (B) it's easy to dismiss things that appear 
> to be too simple - but I would feel remiss if I didn't at least ponder it, 
> so I have been, and I find (reluctantly) that it makes an awful lot of 
> sense.
>
> Consider the most generic interface possible for a contract like "takes a 
> request, returns a response" - this:
>
> interface Middleware {
> public function process(RequestInterface $request): ResponseInterface;
> }
>
> Okay, so that looks more like a front-controller or something - that can't 
> be "middleware", because there's no way to delegate to the next middleware 
> component on the middleware-stack, right?
>
> But there is - you just apply normal OOP and use dependency injection
>
> class RouterMiddleware implements Middleware {
> /**
>  * @var Router
>  */
> private $router;
>
> /**
>  * @var Middleware $next
>  */
> private $next;
>
> public function __construct(Router $router, Middleware $next) {
> $this->router = $router;
> $this->next = $next;
> }
>
> public function dispatch(RequestInterface $request): ResponseInterface 
> {
> if ($this->router->matches($request)) {
> return $this->router->handle($request);
> }
> return $this->next->process($request);
> }
> }
>
> The fact that this middleware may not always be able to process the 
> request itself is reflected by it's required constructor argument for 
> another middleware to potentially delegate to.
>
> Some other middleware might always return a response, and isn't able to 
> delegate at all - it's constructor signature will correctly reflect that 
> fact:
>
> class NotFoundMiddleware implements Middleware {
> public function __construct() {} // doesn't accept other middleware
>
> public function dispatch(RequestInterface $request): ResponseInterface 
> {
> return new Response(...); // 404 not found
> }
> }
>
> The dependencies of each middleware is correctly expressed by the 
> individual constructor of each middleware.
>
> You compose a "middleware stack" not as a data-structure, but simply by 
> proxying each middleware with another middleware:
>
> $stack = new ErrorHandlerMiddleware(
> new CacheMiddleware(
> new RouterMiddleware(
> new Router(...),
> new NotFoundMiddleware()
> )
> )
> );
>
> This visually and logically reflects the "onion" structure that is often 
> used to describe how middleware works, which is not apparent from the flat 
> array-based structure used by current middleware dispatchers.
>
> If you're not comfortable with the nested structure, you could of course 
> arrange the code to make it look more like a stack as well, e.g. decorating 
> a kernel layer by layer, from the inside-out:
>
> $kernel = new NotFoundMiddleware();
> $kernel = new RouterMiddleware(new Router(...), $kernel);
> $kernel = new CacheMiddleware($kernel);
> $kernel = new ErrorHandlerMiddleware();
>
> You can't make this stack appear "upside down" the way it does with most 
> existing middleware stacks - while that is visually appealing, because you 
> can imagine the request coming in from the top and moving towards the 
> bottom, that doesn't reflect what's really going on. It's the other way 
> around - the inner-most middleware is a dependency of the next middleware 
> out, and so on.
>
> What you're building is an HTTP kernel, which is in fact not a stack, but 
> a series of proxies or decorators - so the code is going to reflect the 
> dependencies of the each component, rather than the flow of a request being 
> processed.
>
> Since there is no stack, no "runner" or "dispatcher" is required to 
> dispatch the HTTP kernel at all:
>
> $response = $kernel->process($request);
>
> In other words, no framework is required to implement the layer-like 
> behavior that current middleware dispatchers "simulate" - the layered 
> structure is inherent in the design, and the requirements of each layer, 
> and whether or not it accepts a delegate, is formally defined by the 
> constructor of each middleware component.
>
> This also means you can't compose a middleware stack that might topple 
> over - you won't be able to create such a stack at all, because the only 
> way to construct a valid 

Re: [REVIEW] PSR-11 Container Interface

[Matthieu Napoli]

Larry,



> Unsurprisingly I'd favor PR 3: Explicit exception.

> 

>  I'll be honest that I'm still very confused why there's so much
>  resistance from the Editors on using exception types for what they're
>  supposed to be used for.  Different error condition, different
>  exception.  In 20 years of writing code I cannot recall ever saying
>  "damn, this error message is too precise and specific".  I have said
>  the opposite more times than I can count.


David works on his personal time to implement something that you want,
we both say that we are ready to accept that change if you think this is
mandatory for you to accept the spec, I don't see how you can call that
"resistance" but maybe that's just a wording issue and I shouldn't take
too much notice of that.


Also I just want to point out that of course there should be very
precise and explicit exceptions, we all agree on that. It's just that
we don't believe the interface (as such, the spec) makes sense because
you wouldn't need to catch it. Implementors *should* make very explicit
exceptions. Anyway, again this is just my opinion and I understand you
may not share it, I just want to make sure we are talking about the
same thing.


> PR 1 would resolve the awkward wording, although I do feel it is the
> inferior approach as it is less precise and provides less contextual
> information for callers.  (That we don't at the moment know when a
> caller would want that extra information is, IMO, irrelevant as it's
> so easy to provide.)
> 

>  PR 2 actively works to make using the spec harder, and I cannot get
>  behind that at all.
> 

>  I am admittedly unlikely to vote +1 on the spec regardless, but
>  should it pass anyway I feel it should still be as good (or least
>  bad) as possible, and that is PR 3.


If I understand correctly you might vote -1 because:



> That is, with that [the dependency lookup feature] removed, what's
> left to standardize?  get() and has() are barely an specification.


What do you think of the fact that some frameworks (Slim, Zend
Expressive, Silly…) or some libraries (Behat…) are able to integrate
with any container thanks to ContainerInterface? Do you disagree it
justifies the existence of PSR-11?


Matthieu

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

Re: [VOTE] First Core Committee Elections

[Matthieu Napoli]

Hi everyone,

Here are my votes:

   - Matthew Weier O’Phinney 
   - David Négrier 
   - Sara Golemon  
   - Beau Simensen 
   - Lukas Kahwe Smith 
   - Gary Hockin 
   - Cees-Jan Kiewiet 
   - Michael Heap 

Matthieu Napoli

Le vendredi 9 décembre 2016 17:47:36 UTC+1, Michael Cullum a écrit :
>
> Hi all,
>
> We’ve finally got to the voting stage in the first set of Core Committee 
> Elections where 12 CC members will be elected to staggered terms.
>
> Candidates List (Alphabetical)
>
> 
>
> View full list of candidates with twitter handles and links to nomination 
> topics here <http://bit.ly/cc-election-candidates> (
> bit.ly/cc-election-candidates) or a list of names in copy/pasteable 
> format below.
>
> Beau Simensen
>
> Cees-Jan Kiewiet
>
> Chris Tankersley
>
> David Négrier
>
> Gary Hockin
>
> Graham Daniels
>
> Jason Coward
>
> Jeremy Coates
>
> Korvin Szanto
>
> Larry Garfield
>
> Lukas Kahwe Smith
>
> Marc Alexander
>
> Matthew Weier O’Phinney
>
> Michael Heap
>
> Samantha Quiñones
>
> Same Minée
>
> Sara Golemon
>
> Stefano Torresi
>
> Steve Winter
>
> Tobias Nyholm
>
> Role of the CC
>
> --
>
> The brief summary of the new FIG structure is summised in bit.ly/fig-3-0. 
> The quote pertaining to ‘What is the CC’ is:
>
> They hold the entrance votes and final acceptance vote. These votes are to 
>> see if the FIG wants to consider this problem for a PSR, and to have 
>> oversight of Working Groups and make sure working groups have all relevant 
>> stakeholders have their interests represented within them. Their final 
>> acceptance vote is on the quality of the spec, ensuring consistency 
>> throughout the FIG, ensuring it meets the FIG’s overall direction and aims, 
>> making sure stakeholders interests were represented, and the competence of 
>> the working group.
>
>
> Essentially they are a technical steering committee for the PHP FIG and it 
> is designed to represent (and be representative of) the entire PHP 
> ecosystem from different types of PHP project (Framework, Library, Consumer 
> Package) to non-PHP things that relate to the ecosystem like PHP Runtimes, 
> IDEs, PHP in business to different generalised areas of specialty such as 
> security or async.
>
> Who can vote?
>
> 
>
> You can vote if you are
>
>- 
>
>A project member
>- 
>
>Have been active in the FIG group’s discussions or activities within 
>the past 12 months and are listed here <http://bit.ly/cc-voters> (
>http://bit.ly/cc-voters).
>
>
> If you wish to be on the list of community members please see here 
> <https://gist.github.com/michaelcullum/9f5fd32efce27fb5517dd43bf814f16f#file-xnotetocandidates-md>
>  
> about how to be added. Votes of anyone not on the list will be discarded.
>
> How to vote?
>
> ---
>
> The voting system used is STV[1][2], so basically, there is no tactical 
> voting possible; 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. 
>
> You may, if you wish, not rank all twenty candidates but only rank those 
> with whom you have a preference (top 5, 12, 15 etc.).
>
> Reply to this topic ranking the candidates in order of preference for 
> example:
>
> 1. Luke
>
> 2. Leia
>
> 3. Anakin
>
> 4. Rey
>
> 5. Padmé
>
> 6. Finn
>
> The vote ends at 23:59 UTC on the 23rd December, and the result will then 
> (hopefully/likely) be announced on the 24th December.
>
> Note to candidates:
>
> --
>
> People have asked about this so to clarify, you are highly encouraged to 
> vote for yourselves. For full rationale please see here 
> <https://gist.github.com/michaelcullum/9f5fd32efce27fb5517dd43bf814f16f#note-to-candidates>
> .
>
> Many thanks,
>
> Michael Cullum
>
> [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/9c129d5e-8bde-4563-9761-07d8cf9e1eea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthieu Napoli]

Hi,

This is a good point. However there's a discussion about removing the 
delegate lookup entirely from PSR-11 
here: https://groups.google.com/forum/#!topic/php-fig/9YAFG4Xw2zo That 
would remove that issue I think.

Cheers
Matthieu

Le samedi 3 décembre 2016 18:10:16 UTC+1, Michael Mayer a écrit :
>
> The current version is very confusing:
>
>> 1.4 Additional feature: Delegate lookup
>> This section describes an additional feature that *MAY* be added to a 
>> container.
>> …
>> Implementation of this feature is therefore *RECOMMENDED*.
>
>
> From RFC 2119 :
>
>> 3. *SHOULD*   This word, or the adjective "*RECOMMENDED*", mean that 
>> there
>>may exist valid reasons in particular circumstances to ignore a
>>particular item, but the full implications must be understood and
>>carefully weighed before choosing a different course.
>> …
>> 5. *MAY*   This word, or the adjective "*OPTIONAL*", mean that an item is
>>truly optional.  One vendor may choose to include the item because a
>>particular marketplace requires it or because the vendor feels that
>>it enhances the product while another vendor may omit the same item.
>>An implementation which does not include a particular option MUST be
>>prepared to interoperate with another implementation which does
>>include the option, though perhaps with reduced functionality. In the
>>same vein an implementation which does include a particular option
>>MUST be prepared to interoperate with another implementation which
>>does not include the option (except, of course, for the feature the
>>option provides.)
>
>
>
> Thus, as an implementer, *MAY* or *SHOULD* I implement the delegate 
> lookup feature?
>
> Regards,
> 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/9ca3fee6-614f-4912-92fe-906ddf71daf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[Matthieu Napoli]

> This way I can catch all container exceptions using
> ContainerException, or the individual exception I am interested in. In
> your example, it would not be possible to catch only exceptions raised
> by the container, as other Exceptions could be raised (if for example
> pulling service config from database or memory, or using an HTTP
> request, these services may raise uncaught exceptions).


Again, can we get an actual use case where one would need to catch
MisconfiguredException (or whatever the name) separately from
\Exception? We still have had no answer to that.


> Personally, I would handle missing services differently to a general
> container error and would be keen to see the spec reflect this


NotFoundException is already a thing in the spec, do you have something
else in mind?

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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/1479920713.146140.797206121.5D4CB9FE%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthieu Napoli]

I'm fine with both option (include or don't include it in PSR-11).

As you said David, it's a design pattern. We don't *need* to standardize it 
to use it. Containers that want to do stuff like that can, it's not 
required for decoupling frameworks from containers.

If it's really needed it could be a separate PSR, now that most of the work 
is done it could be easy to write, but probably it won't even be necessary.

> My main concern is that as presented the delegate feature is not really a 
feature, more a "by the way, here's this cool thing you can do."

Agreed.

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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/cceb9980-a331-4a79-89ed-1d1bcdd1d2ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[Matthieu Napoli]

>
> https://github.com/php-fig/fig-standards/pull/844
>
> As far as use case, beyond the semantic distinction "missing" implies the 
> caller is doing something wrong.  "Broken" means the configuration is 
> wrong.  (Even if the configuration in this case is a hard-coded class, it's 
> still configuration so it's in-scope for PSR-11, not PSR-11-followup.)  
> Those would imply different people are doing something wrong, so it's a 
> different person's responsibility to fix.
>

I'm sorry but I still don't see a use case can you lay it out clearly?

An exception exists to be caught, when would you need to catch it and not 
catch \Exception?

Matthieu

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

Re: [REVIEW] PSR-11 Container Interface

[Matthieu Napoli]

Hi Chuck, good point I've opened a PR to fix 
that: https://github.com/php-fig/fig-standards/pull/832

For those not aware I just wanted to point out that topics in this thread 
are being discussed in separate threads on the mailing list. That helps to 
keep up with each discussion. If a topic was overlooked please open a 
thread on the mailing list.

Matthieu

Le samedi 5 novembre 2016 14:33:07 UTC+1, Chuck Burgess a écrit :
>
> Small point: should the has() section in 1.1 say that the entry identifier 
> MUST be a string, similar to how it does so for get()?
>
> On Oct 26, 2016 8:28 AM, "Matthew Weier O'Phinney"  > wrote:
>
>> Hello, everyone!
>>
>> PSR-11, Container Interface (née container-interop) has been in 
>> incubation for a
>> couple years now, and the editor and sponsors feel it is ready for 
>> review. As
>> coordinator, I hereby open the mandatory review period prior to a formal
>> acceptance vote; voting will begin no earlier than 13:30 UTC on Wednesday,
>> November 9th, 2016.
>>
>> For the current version, please reference:
>>
>> - 
>> https://github.com/php-fig/fig-standards/blob/a47c644f9d0f914bb0a9777eeaec157f2d51dbff/proposed/container.md
>> - 
>> https://github.com/php-fig/fig-standards/blob/a47c644f9d0f914bb0a9777eeaec157f2d51dbff/proposed/container-meta.md
>>
>> The related library containing the interfaces is here:
>>
>> - https://github.com/php-fig/container
>>
>> Additionally, a large number of projects either implement or consume
>> container-interop already, and would be (relatively) immediately 
>> compatible:
>>
>> - 
>> https://github.com/container-interop/container-interop#compatible-projects
>>
>> Please familiarize yourself with the specification and its scope, and 
>> reply on
>> this thread with any concerns.
>>
>> Thanks!
>>
>> --
>> Matthew Weier O'Phinney
>> mweiero...@gmail.com 
>> https://mwop.net/
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to php-fig+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/CAJp_myX6QenJQtgmkDYRmJp6ffEaCfO3gDDKHOur1Sq4biLWRw%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/df3e517a-1fb6-41bc-8cf0-3b4b7ea873ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthieu Napoli]

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 big break for no
gain in most cases.

If a server-side middleware needs to call the root middleware it can
still be injected in its constructor (dependency injection). The
point of Joel was that it was a much more common scenario for HTTP
clients IIRC.

Le Jeu 03 nov 2016, à 14:38, Michael Mayer a écrit :
> 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't find it.
>
> Michael
>
> Am Donnerstag, 3. November 2016 08:47:15 UTC+1 schrieb Matthieu
> Napoli:
>> 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 maybe mean we can get rid of the dual
>> "MiddlewareInterface" and "ServerMiddlewareInterface"?
>>
>> Matthieu
>>
>> Le mercredi 2 novembre 2016 23:28:59 UTC+1, Michael Mayer a écrit :
>>> Woody,
>>>
>>> I have no experience in standardization processes, hence everything
>>> is acceptable to me. However, I see an additional benefit of two
>>> PSRs: it would be much easier to superseded them independently –
>>> hopefully that does never happen ;)
>>>
>>> Best regards,
>>> Michael
>>>
>>> Am Montag, 31. Oktober 2016 14:50:39 UTC+1 schrieb Woody Gilk:
>>>> Michael,
>>>>
>>>> Thanks for bringing this up. For historical context, I have always
>>>> thought of "client middleware" as middleware that does not require
>>>> the additional methods defined in ServerRequestInterface. The
>>>> consideration of async vs sync requests was never something that
>>>> entered my mind.
>>>>
>>>> Reviewing the Guzzle docs again (as the most mature PSR-7 client-
>>>> focused package I know of) it certainly appears that the current
>>>> PSR-15 signatures would not work there. That is obviously a serious
>>>> flaw.
>>>>
>>>> However, since there is not currently a ratified PSR for async,
>>>> perhaps the best thing to do would be to repurpose PSR-15 to be
>>>> entirely server-focused middleware? I would rather defer the
>>>> creation of a spec for client middleware until the async PSR is
>>>> complete.
>>>>
>>>> Would that be an acceptable situation for you? I don't want to
>>>> create something that async clients will never be able to use.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Woody Gilk
>>>> http://about.me/shadowhand
>>>>
>>>> On Sat, Oct 29, 2016 at 4:47 PM, Michael Mayer
>>>> <mic...@schnittstabil.de> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I'm a little bit surprised to see so many suggestions about how
>>>>> ServerMiddlewareInterface and ClientMiddlewareInterface should
>>>>> look like, obviously without much knowledge about the client-side.
>>>>>
>>>>> The current state[1] is:
>>>>>
>>>>> interface MiddlewareInterface {}
>>>>>
>>>>> interface ClientMiddlewareInterface extends MiddlewareInterface {
>>>>> public function process(RequestInterface $request,
>>>>> DelegateInterface $next); }
>>>>>
>>>>> interface ServerMiddlewareInterface extends MiddlewareInterface {
>>>>> public function process(ServerRequestInterface $request,
>>>>> DelegateInterface $frame); }
>>>>>
>>>>> interface DelegateInterface {public function
>>>>> next(RequestInterface $request); }
>>>>> 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Here are some falsehoods about the client-side, the list seems, by
>>>>> far, not exhaustive.
>>>>>

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

[Matthieu Napoli]

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
  it's OK to use the extra parameters (because you code against the
  implementation)

That's why OOP (and PHP) allows implementations to have more parameters
than defined in the interface (because you stay compatible with the
interface).

Now we usually say "code against interfaces", because obviously that's
much better. But here for container interoperability we have to consider
the fact that not all frameworks can switch containers entirely.  So
some pieces of code will still use the implementation, that's why we
have to be compatible with this.

In any case, it doesn't make sense that an interface forbids extra
optional parameters, because again OOP and PHP allows it. The question
is whether we want to make that explicit or not in the document: I
usually like explicit because it removes confusion for implementors
(DIC authors).

Matthieu

Le Jeu 03 nov 2016, à 09:21, Niklas Keller a écrit :
>> 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 parameters are *not* fine. It hurts interoperability. If a
> consumer passes them, it assumes a concrete implementation. If the
> implementation is swapped, they might be ignored, but it's even worse
> if that implementation also has optional parameters, then they might
> be interpreted wrongly.
>
>> Because we obviously want to keep all containers compatible.
>
> They *are* still compatible, because these parameters are *optional*,
> so don't have to be provided.
>
>> I just don't want to force implementations to have exactly 1
>> parameter, which doesn't make sense in PHP and in OOP in general
>
> Yes, it does make sense. If you only code to interfaces, optional
> parameters that are not defined in the interface do not make sense.
>
> --
>  You received this message because you are subscribed to a topic in
>  the Google Groups "PHP Framework Interoperability Group" group.
>  To unsubscribe from this topic, visit
>  https://groups.google.com/d/topic/php-fig/zY6FAG4-oz8/unsubscribe.
>  To unsubscribe from this group and all its topics, 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/8dc6ee8a-7459-4a29-91d3-6ea6fa028c69%40googlegroups.com[1].
>  For more options, visit https://groups.google.com/d/optout.


Links:

  1. 
https://groups.google.com/d/msgid/php-fig/8dc6ee8a-7459-4a29-91d3-6ea6fa028c69%40googlegroups.com?utm_medium=email_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 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/1478162568.403962.775978177.0CD102FC%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-11] Exceptions

[Matthieu Napoli]

Splitting off the main review thread, quoting Larry:

> 1) What other exceptions might get($id) throw besides NotFoundException? 

\Exception (because any exception could be thrown when creating services) 
=> are you suggesting we should document it in the standard?

> 2) I would much prefer to see a DependencyNotFoundException defined for 
that case than leaving that up to individual implementers. Standard 
error handling is just as important if not moreso than the happy path. 

Why/when would one want to catch that exception (use case)? This is not a 
need we have seen when using container-interop as of now, I'm of course not 
against adding new stuff but we should do it for a reason.

Matthieu

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

Re: Comments please: Asset Scheme

[Matthieu Napoli]

Hi Rasmus,

I was going to mention Puli too. Not because of all its features, but 
because it contains a very simple solution to a wider problem: locating 
resources.

Puli encourages to have a `res/` directory containing all resource files 
(just like `src/` contains all source files). Resources include assets, 
configs, templates, etc. Because the problem with everything that is not a 
source file is "how to locate it" (for source files we have the autoloader).

Once an application can locate assets, it can publish them, minify them, 
etc. The standard would avoid deciding what to do with assets (whereas your 
proposition only solves how to expose them, which is quite restrictive). 
The less the standard expects the better.

Matthieu

Le mardi 18 octobre 2016 10:08:56 UTC+2, David Négrier a écrit :
>
> Hey Rasmus,
>
> Another thing came to my mind. Your proposal looks awfully similar to Rob 
> Loach's component system.
> Have you had a look at it? => 
> http://robloach.github.io/component-installer/
> Any thoughts about that? Shouldn't we consider building on this existing 
> example?
>
> The difference is that Rob Loach has an implementation of a Composer 
> installer instead. So rather than working on a specification, he directly 
> created an implementation. Which is actually fine because you don't need a 
> framework for your assets to be copied (they are copied/linked by the 
> component-installer composer plugin that is a dependency of your asset 
> package).
> What would be the value of an Asset-PSR (if you want to build a PSR out of 
> it), instead of Rob's direct implementation?
>
> Best regards,
> David.
>
>
> Le lundi 17 octobre 2016 21:57:20 UTC+2, Rasmus Schultz a écrit :
>>
>> A lot of people do a lot of things wrong. In my opinion, it's better to 
>> create simple things that are easy to learn to use correctly - as opposed 
>> to creating complex things that supposedly shield you from making mistakes. 
>> Often such things provide only a false sense of security - and usually you 
>> can break them and hurt yourself anyhow.
>>
>> Most server side components have some kind of client side footprint - 
>> URLs or HTML class names etc which can be used to figure out what you're 
>> running.
>>
>> I really don't think it's within the scope of this specification to teach 
>> OWASP 101? Package names are obviously revealed in the URLs - it's hardly a 
>> hidden detail, it's basically the whole concept.
>>
>> In my opinion, there is no security problem inherent in this idea, unless 
>> you create one. 
>>
>> On Oct 17, 2016 9:30 PM, "Sven Sauleau"  wrote:
>>
>>> Using this standard, people can know what packages you are using because 
>>> of its predictable paths. Some packages are running server-side code as 
>>> well as exposing public assets.
>>>
>>>
>>> I said (in the comments of the gist) that exposing stuff is the 
>>> responsibility of the developer. I’m sure some people will be confused and 
>>> disclose informations they shouldn’t (as mention by Fabien).
>>>
>>> Le lundi 17 octobre 2016 16:43:25 UTC+9, Rasmus Schultz a écrit :

 I wrote a draft for a simple scheme for the inclusion of static assets 
 in (Composer) packages.

 https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee

 Not submitting this or anything, just dumping it here to start a 
 discussion :-)

 Thoughts?

 -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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/c2ba50bb-ad74-4675-8ccd-08cdd8a360a0%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/e4f0f008-ab9f-4592-8d6e-edab03812447%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Delegate Lookup > Interface Proposal

[Matthieu Napoli]

Hi!

This is a lot of text, I'm still not sure I understand the problem we are 
trying to solve in this thread?

> The `ParentAwareContainerInterface` is a formal way of saying "this 
container can have a parent". Nothing more, nothing less.

Then we are back to discuss "marker-interface" VS "no-interface", which has 
already been discussed for a long time: if the interface is useless it 
shouldn't exist.

> Thus, this interface is useful to any consumer that needs to be 
hierarchy-aware. Up to now, there is no concept of hierarchy in the 
standard, and the use of the interface would be to introduce that concept.

Can you point to a real use case that is being used in the wild, and that 
deserves to be part of a PSR (i.e. that is part of the 80%-90% problem, not 
just a very isolated use case)?

I understand that a few edge case things *might* be possible with it, but 
the very important question is "do we need it?"

Matthieu

Le lundi 10 octobre 2016 14:21:55 UTC+2, Xedin Unknown a écrit :
>
> Just wanted to add something.
>
> If I understood correctly, David suggested that all hierarchy is flattened 
> so that all containers have the same parent - the root container - for the 
> sake of faster lookup. If that is true, than I would like to remind 
> everyone that in my proposal, the amount of nesting is implementation 
> detail. If the DI implementation wants to have the same parent for all 
> containers, *they can do that*. However, I don't see why they must be 
> required to do that.
> My demo implementation would work just the same if there was one level, 
> without having to change anything.
>
> Thanks.
>
> I remain,
> Anton.
>
> On Monday, October 10, 2016 at 12:48:56 PM UTC+2, David Négrier wrote:
>>
>>
>> 
>>
>>
>>
>> 
>>
>> Hey,
>>
>> Ok I spent the week-end trying to think about the pros and cons of this 
>> proposal.
>>
>> @XedinUnknown, I'm not sure I understood 100% of your proposal so I'll 
>> try to rephrase it. If I'm wrong, let me know.
>>
>> I understand you are trying to improve the "delegate lookup feature". 
>> Your goals are:
>>
>> - to make it "explicit" that a container is implementing the "delegate 
>> lookup feature"
>> - to make it possible to nest containers at an unlimited level (to be 
>> able to nest a composite container in another composite container...)
>>
>> To do so, you propose to add a new interface named 
>> ParentAwareContainerInterface 
>> .
>>  
>> This interface is exposing a single method "getParentContainer()" that 
>> returns the parent container if any (i.e. the composite container 
>> containing this container).
>> When resolving a dependency, the container goes up the chain of parent 
>> containers 
>> 
>>  
>> until it reaches the root container. It uses the root container to look up 
>> any dependency (just like in the current delegate lookup feature).
>>
>> Here are a few thoughts about this idea:
>>
>> First: who is consuming the ParentAwareContainerInterface 
>> ?
>>  
>> This interface is consumed by "child" containers. If a container is a leaf 
>> in the container tree (so if it is not a composite container), then there 
>> is no need for it to implement the ParentAwareContainerInterface 
>> .
>>  
>> The interface is trivial to implement and is a good declaration of intent 
>> (your container states it supports delegate lookup feature) but it is none 
>> the less useless. This interface is only useful for composite containers 
>> (so that they can also be bundled into parent composite containers).
>>
>> Second, each container now needs to find the root container by going up 
>> the container tree. In your sample, you do this while resolving a service 
>> .
>>  
>> This is a bit of a problem performance-wise because this will slow service 
>> resolving (and this is a major no no for many implementors). Of course, 
>> there is a simple way around that. Finding the root container could be done 
>> only once, possibly in the constructor. This assumes that the parent 
>> container is passed to the child container constructor (or at build time). 
>> This also assumes that the parent container will never change in the life 
>> of a container (this is a safe assumption). Looking at @XedingUnknown code, 
>> this means that stuff like containers 

Re: [PSR-11] Question about PSR-11

[Matthieu Napoli]

> Given that most of PSR-11 was developed "off in a corner" from a FIG POV, 
> I'd strongly suggest that anything people ask about here be taken as a need 
> for clarification in the metadoc (if something isn't there already).  "This 
> GitHub link in this other group you wouldn't know to look for" is a useless 
> answer when (not if) questions arise from people reading the spec in the 
> future after passage.
>

Hi Larry, I agree very strongly with that remark, in fact we take that 
quite seriously :p (as you can see by the length of the meta document) 
Everyone can find all that information and all those links there:

- 
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#5-history
- 
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#6-interface-name
- 
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#11-relevant-links

Regarding the original question this is answered in the document 
too: 
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#31-goals

It is important to distinguish the two usages of a container:
>
>- configuring entries
>
>
>- fetching entries
>
> Most of the time, those two sides are not used by the same party. While it 
> is often end users who tend to configure entries, it is generally the 
> framework that fetches entries to build the application.
> This is why this interface focuses only on how entries can be fetched from 
> a container.


 Any kind of improvement in the wording is welcome. I have taken a few 
sentences from Matthew's response and reworded it a bit, maybe we could add 
in this section:

> Another reason the idea of "adding services" is being considered 
separately is because there's a ton of approaches, and not a lot 
of commonalities between them. Determining what the minimum set of features 
to support is proving to be quite difficult, and as such is being worked 
upon in a separate PSR.

> In the meantime, PSR-11 is useful on its own. Containers can be 
configured by the end users, with their custom API. Then PSR-11 containers 
can be provided to compatible applications which will call get() or has() 
to retrieve objects such as a controllers, middlewares, and all their 
related dependencies. 

Thoughts?

Matthieu

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

Re: [PSR-11] Remove ContainerException

[Matthieu Napoli]

Hi all, thanks for participating in this discussion.

While David and I feel the same, it seems we are alone. We do not see real 
usage (not implementations or "what ifs" but actual usage) of that 
interface today (see https://github.com/php-fig/container/pull/2).

However its not worth blocking PSR-11 any longer because of such a detail, 
so let's go with the majority and move forward!

Matthieu

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/449a56fa-defe-48e5-80fc-87348f2409d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Matthieu Napoli]

>
> I agree in so far that we need to acknowledge that there will be PSRs 
> superseding previous PSRs and there will be PSRs that are incompatible to 
> previous PSRs. 
>

Hi Lukas, could you explain what incompatibilities you see?

Just to be clear there is no plan to change any existing PSR. And there is 
no plan to replace them with new PSRs that adopt the new convention.
And if a new PSR depends on another currently existing PSR, it will use the 
existing names, not new (non-existing) ones. Example: PSR-15 should use 
`RequestInterface`, it shouldn't use `Request` just because of the new 
convention (because obviously it will not work: the interface does not 
exist under that name).
The goal is not to break anything, if you see such a scenario let's discuss 
it.

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

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Matthieu Napoli]

The question of consistency with existing PSRs has been raised a lot. I 
don't see that as a problem.
It's OK to move forward and change a convention if we want to, each PSR is 
independent from the rest. Consistency for this is a very small detail 
compared to developer experience, we shouldn't limit improvements for no 
tangible reason.

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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/563037a1-0875-4374-b5d2-e662c5ebbc64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Matthieu Napoli]

Hi Woody,

This is not about personal preferences, this is about solving a pain point for 
everyone. That example is pretty much explicit:

public function __invoke(ServerRequestInterface $request, ResponseInterface 
$response, callable $next) : ResponseInterface
{
}

Activé 18 août 2016 à 02:08:16, Woody Gilk (woody.g...@gmail.com) a écrit:


On Wed, Aug 17, 2016 at 4:53 PM, Roman Tsjupa  wrote:
It is not about being right or wrong really. Its more about being strict for no 
good reason. Its a backwards compatible change, so if you like you can still 
suffix your interfaces.


Roman, the reason FIG exists is that it takes personal choice out of the matter 
and thereby provides consistency. This proposal does neither.

--
Woody Gilk
http://about.me/shadowhand
--
You received this message because you are subscribed to a topic in the Google 
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/php-fig/Potawlu2CrQ/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAGOJM6KqQSZMykis%2B6676Toh7VyHL0byTTEgCPJ%2BFZioFawF7g%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/etPan.57b555d4.63f2dccc.16394%40mnapoli.fr.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Matthieu Napoli]

Thanks a lot for the detailed response Matthew.

If you already discussed that then sorry for wasting your time (and others 
too), your answer sounds valid to me I wasn't expecting such a high level 
of backward compatibility with existing systems.

To avoid repeating that discussion in a few months I have taken the liberty 
of picking a few of your sentences and write a summary of that in the META 
document: https://github.com/php-fig/fig-standards/pull/807

Now it seems the only topic worth discussing is the name? Rasmus you 
suggested `DelegateInterface` instead of `FrameInterface`, that sounds like 
an improvement to me (I have nothing better to suggest), what do others 
think?

Le mercredi 17 août 2016 16:05:57 UTC+2, Matthew Weier O'Phinney a écrit :
>
> On Sun, Aug 14, 2016 at 12:47 PM, Larry Garfield <la...@garfieldtech.com 
> > wrote: 
> > On 08/14/2016 12:32 PM, Matthieu Napoli wrote: 
> > 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
> > 
> > 
> > I believe the argument MWOP made in the past is that many existing 
> > middleware systems already use __invoke(), so PSR-15 using __invoke() as 
> > well would make bridge code harder.  A separate method makes having an 
> > object that just calls the method from an existing __invoke() (or vice 
> > versa) trivial. 
>
> That was indeed the argument. 
>
> Since many (most) existing middleware systems already use either 
> callables or a class/interface that implements `__invoke()` for the 
> `$next` argument, specifying the interface within this PSR to define 
> `__invoke()` has the potential to make it completely incompatible with 
> these existing systems without major changes. 
>
> As an example, consider a middleware that targets this PSR, but is 
> dropped into Expressive or Slim, and then calls on $next: 
>
> return $next($request); 
>
> In each of these cases, a second argument *is required currently*, 
> which means that this invocation will result in a fatal error. 
>
> If we instead use another method entirely, the above becomes something 
> like: 
>
> return $frame->next($request); // or: 
> return $delegate->next($request); // or: 
> return $delegate->process($request); // etc. 
>
> As a result, these existing libraries can implement the interface 
> without breaking backwards compatibility: 
>
> class Next implements DelegateInterface 
> { 
> public function __invoke(ServerRequestInterface $request, 
> ResponseInterface $response) 
> { 
> // ... 
> } 
>
> public function next(ServerRequestInterface $request) 
> { 
> // ... 
> } 
> } 
>
> allowing them to mix-and-match middleware written for the previous 
> version with middleware targeting this PSR. Since the new interface 
> method only indicates one required argument, the implementation can 
> even pass the response to ensure backwards compatibility, and provide 
> tools for scanning middleware to warn about implementations that need 
> to be updated. 
>
> While I appreciate that we want to standardize on what is already 
> being done, the fact that the calling patterns of existing middleware 
> dispatchers vary currently means that having a discrete, unique method 
> ensures greater compatibility once the specification is finalized, 
> easing the way to adoption by existing libraries. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@gmail.com  
> https://mwop.net/ 
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8ea2fb90-2d69-484c-9b53-bec40722a17b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Matthieu Napoli]

Hi Chuck,

Are you using ContainerInterface or do you plan to use it in PEAR? If
so, in which scenario would that exception be useful?
The goal is to collect such scenarios to see if that specific interface
serves any purpose.

You are welcome of course to create a base exception class (or
interface) in PEAR's container package to satisfy your internal
conventions.

Matthieu

Le Mer 17 août 2016, à 12:57, Chuck Burgess a écrit :
> PEAR most definitely wants to keep the package-level base exception,
> as it is a convention we always expect to be available.  We have
> *required* this for years, originally as a class in PEAR1 standards,
> until we came up with the idea of it instead being an interface while
> working on the PEAR2 standards.  We were quite happy with its
> demonstrated benefits, which proved even better as an interface than a
> class [1], and were tickled to see the use of it spread into the
> community after we published it.
> We would prefer to *not* lose the base exception interface
> requirement.
>  CRB
> [1] -- https://wiki.php.net/pear/rfc/pear2_exception_policy
>
> On Aug 15, 2016 7:35 PM, "Paul Jones" <pmjone...@gmail.com> wrote:
>>
>> > On Aug 15, 2016, at 14:10, Matthieu Napoli <matth...@mnapoli.fr>
>> > wrote:
>>  >
>>  > Hi,
>>  >
>>  > PSR-11, aka ContainerInterface, has been sleeping for too long.
>>  > Let's get that PSR moving!
>>
>>  Woohoo!
>>
>>
>>  > Here is a change I would like to suggest: remove the interface
>>  > ContainerException.
>>  ...
>>  > After years of using container-interop and ContainerInterface I
>>  > have not seen a use case for that exception. We initially added it
>>  > to represent any exception that could happen in a container.
>>
>>  On principle alone, I usually like to see a package-specific base
>>  exception class, so that you can catch any/every exception from a
>>  particular package. (Maybe that's more an unnecessary consistency on
>>  my part.)
>>
>>
>>  --
>>
>>  Paul M. Jones
>> http://paul-m-jones.com
>>
>>
>>
>>  --
>>  You received this message because you are subscribed to the Google
>>  Groups "PHP Framework Interoperability Group" group.
>>  To unsubscribe from this group and stop receiving emails from it,
>>  send an email to php-fig+unsubscr...@googlegroups.com[1].
>>  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/325BF45B-4638-43AA-9D6F-59BADB38C65E%40gmail.com.
>>  For more options, visit https://groups.google.com/d/optout.
>
> --
>  You received this message because you are subscribed to a topic in
>  the Google Groups "PHP Framework Interoperability Group" group.
>  To unsubscribe from this topic, visit
>  https://groups.google.com/d/topic/php-fig/_vdn5nLuPBI/unsubscribe.
>  To unsubscribe from this group and all its topics, 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/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%2BMrJqerRK3gXn6q%2BA%40mail.gmail.com[2].
>  For more options, visit https://groups.google.com/d/optout.


Links:

  1. mailto:php-fig%2bunsubscr...@googlegroups.com
  2. 
https://groups.google.com/d/msgid/php-fig/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%2BMrJqerRK3gXn6q%2BA%40mail.gmail.com?utm_medium=email_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 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/1471433444.1345100.697863737.35716C31%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Matthieu Napoli]

Hi all,

This is a 2 weeks discussion before going to a vote.

The "Interface" suffix has been questioned a few times already, I'm 
suggesting we put that up to a vote and avoid future debates. Here are 
relevant threads I could find on the topic:

- https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
- https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
- https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
- https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion

Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be 
suffixed by Interface"* 
from http://www.php-fig.org/bylaws/psr-naming-conventions/

I do not suggest accepted PSRs are changed.

Please share your reasons to vote FOR or AGAINST the change, let's debate 
for 2 weeks or more, and then let's have a vote to settle this.

Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).

---

Here are my arguments to vote FOR the change:

*- the Interface suffix makes simple names very long*

For example with PSR-7, here is the signature of a Slim/Zend Expressive 
middleware:

public function __invoke(ServerRequestInterface $request, ResponseInterface 
$response, callable $next) : ResponseInterface

{

}


Compare that to:

public function __invoke(ServerRequest $request, Response $response, callable 
$next) : Response

{

}


The last one is much simpler and clearer. Typing and reading the first one 
is a huge pain. This point applies of course to all PSRs, not just PSR-7.

*- the Interface suffix makes the interface a detail and the implementation 
the main thing, it should be the other way around*

We should care about the interface, not the implementation. Type-hinting 
against LoggerInterface means that "Logger" (the implementation) is still "
*the* logger", and the interface is a secondary concept that we explicitly 
inject for decoupling.
If "Logger" was the interface, it would be even more obvious that the 
interface is the most important part. The implementation is secondary and I 
don't even care how it's named. I just want a logger and that's what the 
interface is.

Regarding the inconsistency it would create between PSRs I think it's 
nothing compared to what we would gain in terms of developer experience.

Matthieu

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

[PSR-11] Remove ContainerException

[Matthieu Napoli]

Hi,

PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get 
that PSR moving!

Here is a change I would like to suggest: *remove the interface 
ContainerException*.

After years of using container-interop and ContainerInterface I have not 
seen a use case for that exception. We initially added it to represent any 
exception that could happen in a container. But as far I can I see, it's 
never useful, in other words it could as well be "\Exception" and the 
result would be the same. Here is the original discussion that lead to such 
interface: 
https://github.com/container-interop/container-interop/issues/3#issuecomment-33133155

Here is the pull request to remove the 
interface: https://github.com/php-fig/container/pull/2

Just to be clear: I am not suggesting to remove NotFoundException, this 
exception is useful.

If anyone has ever seen a use case for that exception, please let me know :)

Matthieu

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/59dfaa6f-9cb4-49f6-8c83-d248e8567532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] Why StackInterface? And why is it not a middleware?

[Matthieu Napoli]

Thanks Woody for your answer. Such information should be in the META 
document, else we are bound to discuss all this over and over.

Back to the topic: I don't see how the interface helps. If I'm writing a 
server middleware stack, I'll type-hint against ServerMiddlewareInterface 
(and vice-versa if it's a client middleware stack). 

> it illustrates the requirement that stacks must be aware of  the type 
hint of the middleware being added to the stack [1]. If the stack  ONLY 
accepts client middleware, it MUST type hint against 
 ClientMiddlewareInterface. If it accepts both server and client 
 middleware, it MUST type hint against MiddlewareInterface. 

Right, so how is the interface helping since it's type-hinting against the 
root "MiddlewareInterface"? It will prevent implementors from type-hinting 
against a more specific interface so I don't see the point. I'm missing 
something here.

> Now it could certainly be argued that having the StackInterface is out of 
scope for the spec and I wouldn't disagree. However, any removal [2] should 
be accompanied by an update to the middleware meta document to describe how 
the type hints should be used.

What do you mean by that?

Thanks!
Matthieu

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

Re: [PSR-15] Why StackInterface? And why is it not a middleware?

[Matthieu Napoli]

Sorry for bringing that topic up again but I'll make it clearer:

*I think the StackInterface should be removed.*

- I don't see what it has to do with PSR-15 (interoperability for *invoking* 
middlewares)?
- even if it was a separate PSR, I don't see the problem it is solving (and 
the META document doesn't help)
- I think the interface itself is very limiting and should be improved (but 
again, I don't think it should exist at all so…)

Do we have any reason to keep it, or should we remove it?

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

Re: [PSR-15] FrameInterface

[Matthieu Napoli]

The term "Frame" is extremely confusing, I think it's a big issue with the 
current version. I'm sure if you showed the current signature to PHP 
developers a majority of them would not understand what that parameter is.

On the other hand `$response = $next($request)` is so simple and widespread…

Yes we loose type safety but there's only one parameter and it's an HTTP 
request, it cannot get simpler than that. Do we really want to complicate 
the standard for no actual gain in real scenarios ?

With PSR-7 middlewares the callable type-hint is not an issue, let's not 
solve a problem that doesn't exist?

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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/98c2c4ed-2415-4b96-a7dd-d91844b0e37c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FIG 3.0 (Including a TL;DR Summary)

[Matthieu Napoli]

>
> Michael,
>
> Please self-throttle a bit. It seems you are over-communicating/defending 
> rather than allowing members to flesh this out.
>

It says right there in his previous email that he realizes he sent 2 emails 
in this thread today and that he will self-throttle. Additionally the 
self-throttle "rule" is 2 posts per topic per day so technically he's doing 
nothing wrong here (unless maybe when looking at it from another timezone…) 
This kind of remark only derails the conversation for no reason.
 

> Perhaps a topic for a different thread, but …
>

If you think this is a different thread then a new thread should be created?

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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/0b93849d-7681-407e-ac61-04ab437d65d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Matthieu Napoli]

Thanks. However I'm still looking for a good reason why we have this 
interface: why not simply `callable $next` ?

- FrameInterface doesn't represent any actual usage or existing middlewares 
today
- FrameInterface is more complex than `callable`

Matthieu

Le mardi 12 juillet 2016 16:39:53 UTC+2, Beau Simensen a écrit :
>
> On Tuesday, July 12, 2016 at 3:26:42 PM UTC+1, Rob Allen wrote:
>>
>> Where did the word "Frame" come from and in what context is it used. It 
>> means nothing to me and I don't think I'm alone in having no clue how I 
>> would be able to infer that $frame might have a next() method. It's very 
>> weird and I think it's a negative when looking at the function signature as 
>> it's a meaningless word unless you know some back story that I clearly 
>> don't?
>>
>> I would love an explanation as it looks to me like an area of confusion 
>> for people new to writing middleware.
>>
>
> I believe it has something to do with the concept of call stacks / stack 
> frames? Reading a bit real fast on that I'm not 100% sure it fits entirely 
> but I think that was the intention.
>
>
> http://stackoverflow.com/questions/10057443/explain-the-concept-of-a-stack-frame-in-a-nutshell
>
> "A call stack is composed of 1 or many several stack frames. Each stack 
> frame corresponds to a call to a function or procedure which has not yet 
> terminated with a return." 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework 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/0c74caa6-bd50-4685-a710-c370b7245472%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-15] Why StackInterface? And why is it not a middleware?

[Matthieu Napoli]

Hi everyone,

I had a look at the spec and at the metadocument, but couldn't find an 
answer to my questions about PSR-15 (HTTP middlewares for those mixing up 
the numbers like me):

- why are middleware stacks not middlewares too?
- as corollary, why StackInterface exists at all?

interface StackInterface{/** snip< withMiddleware() and withoutMiddleware() 
> */
public function process(RequestInterface $request);}


This looks a lot like the signature of a middleware, except it can't call 
"next". I've seen scenarios where it might be useful to have a middleware 
stack inside another middleware (i.e. nested in another middleware stack or 
router) - here is an 
illustration: https://github.com/stratifyphp/router#everything-is-a-middleware 

If we consider middleware stacks just like any other middleware, the 
standard is much simpler and we don't need the StackInterface. It also 
sounds to me like standardizing a middleware stack is out of scope for a 
middleware standard.

I did not forget the 2 other methods of the StackInterface: 
withMiddleware() and withoutMiddleware(). These 2 methods are used for 
configuration, which is often done by users. I don't see why we would want 
interoperability at that level. It's like the LoggerInterface doesn't 
contain methods for configuring the logger.

Cheers
Matthieu

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