*Third-party PSR-7-compatible packages - A, my package - B. Package B can
use any package A and *
*doesn't depend on the implementation of package A. *
*PSR class implements PSR interface (ex: class Stream implements *
*StreamInterface).*
For beginning: I read the recommendations/meta and understand why PSR team
came to this decision.
But in real: this recomendation works only for only for well-known package
A whose structure you know. I will not be able to use* any* package A in
package B.
"PSR-7-compatible" does not imply that package A also implements PSR-17.
Personal
statistics: at least half of packages A not PSR-17-compatible.
I can't create new (or reset) PSR classes (in package B) from not
PSR-17-compatible
package A i.e I can't realize Prototype, Factory patterns.
I see a solution to these problems in merging PSR-7 and PSR-17 in new PSR
as in PSR-12. This will allow:
update current interfaces:
add return type declarations for methods where it need
add methods and fix current docBlock's:
StreamInterface::truncate($length)
UriInterface::withQuery($query) @param iterable $query,
UriInterface::withQueryLine($query)
@param string $queryand + getters
add constants: constant with request methods, protocols
add interface/class exceptions
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/7ddcfe19-5e00-4bc6-ad0f-3beff9d17355%40googlegroups.com.
