On 12/30/2016 10:50 AM, Rasmus Schultz wrote:
> So, for you, any PSR is wrong?
I have been pretty heavily invested in the development of PSR-5 and
PSR-15, and I rely on PSR-7 and others in my work every day.
So no.
If you're trying to dismiss my opinion without actually debating any
of the points I made, that's not the way to go about it.
PSR standards, in my view, are about making things interoperable - not
about reducing every domain entity to a lowest common denominator.
To give you a few practical examples, the cache PSRs do not specify
how a cache is implemented or configured, only how it's consumed. The
middleware PSR does not specify how middleware is implemented or how
the components get created, only how they're dispatched. The logger
PSR does not concern itself with how loggers are implemented, routed,
configured, created, etc. - only how the logger works once it's
created, configured and ready to use.
If a router PSR defines how routers are configured as well as how
they're consumed, how is it you think any logger will be able to
differ from another, in the way it's configured, the features it
offers, or anything else that makes one logger conceptually or
feature-wise different from any other logger?
If you standardize router configuration, you've standardized the
actual feature-set. There will be no practical reason (beyond
performance) to choose any one specific implementation over another -
they will all do precisely the same thing.
The same is not true for things like logging frameworks, cache
back-ends or middleware.
Reducing all practical use of all routers to a lowest common
denominator is meaningless. If you do that, you only need one router,
the fastest one - it doesn't matter if they have different
routing-configuration features beyond the standardized feature-set,
you won't be able to use them.
Being able to dispatch a router without knowing how it was configured
or created is, yes, important - but the same is true for lots of other
components which take a request and produce a response, and middleware
already takes care of that.
So I genuinely don't understand what it is you're trying to accomplish.
In my honest opinion, it sounds like a solution looking for a problem.
I generally agree with Rasmus here. Interface PSRs work best when the
client library consuming it really only has one meaningful way to
interact with the Thing (or the ways to do so can be reduced to one
meaningful way with little to no loss of functionality), but there could
be a variety of different implementations of the Thing for reasons other
than "there are many like it, but this one is mine." Logging is an
extremely good fit for that. Caching is a reasonable fit for that.
HTTP messages are a decent fit for that. Routing? I don't see that as
fitting that model.
--Larry Garfield
--
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/e9776260-11b8-d1e0-8cff-e333bbeb0c36%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
