Re: Routing PSR

Hey Hari, > On 18 Nov 2016, at 06:27, Hari K T wrote: > > I believe , we should allow Router to do one thing, finding / matching the > route, generating the route. Well, I think it should exactly do one thing - namely finding/match the route. The generation is IMHO

Re: Routing PSR

I believe , we should allow Router to do one thing, finding / matching the route, generating the route. Dispatching based on the route should be done by dispatcher. If you are curious what I am talking consider looking into the examples

Re: Routing PSR

What would the use case for that be? I've never seen a system that worked that way. Here is how I would define the interfaces: https://gist.github.com/shadowhand/543e4e507bf90feffd6bc63427c7e53b See comment at the end for implied usage. -- Woody Gilk http://about.me/shadowhand On Thu, Nov 17,

Re: Routing PSR

I didn't realize that you meant only the naming, my fault. Anyway i imagine the RouterMatcherInterface as an object that will contains one or more RouterInterface, and handle the matching of the uri with a Route and will invoke the callable. Example having different RouterInterfaces, the

Re: Routing PSR

I wasn't implying it should be static, just stating naming. I think I agree with you about the first two interfaces. What is the purpose of RouteMatcherInterface? On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro wrote: > I would like to avoid static methods, they are

Re: Routing PSR

On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro wrote: > I'm doing a microframework (for educational purposes), with the goal of use > in the core only methods derived from the PSR interfaces, so as to give > maximum flexibility and not be bound to an

Re: [REVIEW] PSR-16 Simple Cache

Not sure I fully understand that - as a user I can't rely on common sense implementations doing it right. If it's not part of the standard, I can't guarantee it as a feature and I can't use it. My only course of action for using that feature would be tightly coupling to a cache library that

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

Thanks David for such a comprehensive roundup of what's being proposed. I personally found the time and effort you put into explaining the problem a great help. I am against adding this functionality for reasons already stated - I believe it's out of the scope of this PSR and would be an

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

I agree with Alessandro. Since this seems a pretty controversial point, I would drop it, in favor of continuing the discussion into a new separate PSR, or maybe the "add stuff in the container" PSR. PSR-11 is just a stepping stone for everything in this area, so I would prefer to drop it and

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

On 17/11/2016 11:29, David Négrier wrote: I know some of you have doubts about this part of the PSR, so the first thing might be to decide whether we want to keep it or not. If we decide to keep it, I'm sure there are plenty of things we can do to improve the wording :) I see the advantages

[PSR-11] Review of the delegate lookup feature

Ok folks! I've been delaying this for a while to give some room for the rest of the questions about PSR-11, but now is the time to dwelve into the details of the delegate lookup feature :) I know some of you have doubts about this part of the PSR, so the first thing might be to decide whether we

Re: [REVIEW] PSR-16 Simple Cache

We had a quick chat off list and I believe Cees-Jan agrees with me that this is not really feasible as is. Having promise responses without a promise spec is not doable, and having optional promise responses means the interface can not be relied upon at all in libraries as it may return

Re: [REVIEW] PSR-16 Simple Cache

Thanks for the clarifications Larry. On 16/11/2016 23:13, Larry Garfield wrote: The reasoning here for PSR-6 was that a broken cache should not result in a broken program. If your cache is b0rked, then everything becomes a cache miss but the app continues to run, just slowly. (Maybe