Good point, thanks Daniel. Here's another great example of a PSR with the right idea - the Container PSR, which is currently under review:
https://github.com/container-interop/fig-standards/blob/master/proposed/container.md This does not attempt to erase the differences between containers - almost any container can support this interface, which makes the configured containers interoperable. This PSR is excellent for comparison - the concepts, means and methods by which containers are configured are quite radically different, some (like Pimple) don't even use methods at all, so how could you possible standardize on an interface? When it comes to resolving and checking for the existence of a dependency - actually using the configured container - they can all follow this standard, even minimalist Containers like Pimple can support it via an adapter. Imagine for a moment if they had standardized on how containers are configured - you'd have the same situation I described above, there would be zero difference to select any container over any other, except performance, they would all need to do the exact same thing in the exact same way. I think the situation is exactly the same with routers. What makes them different and individually useful or interesting, is what sort of facilities and features they offer in terms of configuration and creation. If you take that away, there is zero reason to have more than one router or container, you would just want the fastest one, done. A good PSR doesn't just reduce everything to the lowest common denominator - providing "maximum flexibility" means making room for things that are as different as, say, Pimple and PHP-DI, and abstracts only what is necessary in order to integrate those components in a consistent way. You don't need to standardize how these components get created or configured - it's not important. If your abstraction removes all the individual strengths and capabilities of each implementation, why would anyone want to implement it? We might as well all agree on one router, then. But that's never going to happen, just like we'll never agree on one DI container, one logging framework, one cache-server... that's not a realistic (or desirable!) goal. On Friday, December 30, 2016 at 6:20:07 PM UTC+1, Daniel Plainview wrote: > > Some things make frameworks special and routing, in my opinion, one of it. > If you want to eliminate this uniqueness among frameworks, you make > pointless to choose between them. > > > give maximum flexibility > > not be bound to an implementation > > These are mutually exclusive statements. > > On Friday, November 18, 2016 at 12:12:16 AM UTC+3, Damiano Petrungaro > wrote: >> >> Hi everyone. >> >> 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 implementation rather than >> another. >> >> Now i'm thinking about a routing system, and i'm wondered, how a so >> crucial component to web applications (used by all the frameworks) haven't >> a standard. >> >> What do you think to propose it as a possible PSR? >> > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/eb337752-1262-4f81-829b-9a105f423ba1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
