On Mon, Oct 14, 2019 at 9:34 AM Anton Fedonjuk <antonfedon...@gmail.com> wrote:
> > *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. > Please explain what you are trying to do with one package that you cannot do with another. Without this information, we're running on your assertion, without any evidence, which makes it impossible to understand what the problem is that you're facing. > "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. > This is perfectly fine. PSR-7 packages do not need to implement PSR-17, and vice versa. It is up to the application developer to compose PSR-17 factories in their container that will provide PSR-7 instances for you. Instances provided by PSR-17 packages will be PSR-7 compatible. You can mix and match, but you will generally want to ensure that the PSR-17 package you use returns instances from the same PSR-7 implementation you chose for your application. > 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. > PSR-17 provides factories, plain and simple. That's all. It does so in predictable ways. But what it provides is fairly minimal, and targeted at the bare minimum of PSR-7 capabilities. If you want specialized streams (e.g., callback streams, binary streams, etc.), you will need to use your own factories or specialized PSR-7 instances (e.g., Diactoros provides a variety of specialized responses such as JsonResponse, XmlResponse, etc.). You can provide your own factories for providing prototypes (this is what Expressive did until version 3). All of this is by design: it provides the _minimum_ API necessary for interop. > 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 > There is a proposal at the FIG level for evolving specifications to adopt both return type hints and argument type hints. If this is ratified, there's no need for a new spec. > add methods and fix current docBlock's: > StreamInterface::truncate($length) > UriInterface::withQuery($query) @param iterable $query, > UriInterface::withQueryLine($query) @param string $queryand + getters > You'll need to provide justification for each of these. We chose not to implement most of these, and have information in the metadocument detailing why. > add constants: constant with request methods, protocols > This latter is provided by the fig/http-message-util package. It is purposely NOT in the spec to allow us to update it as new response status codes and methods are ratified by the IETF. > add interface/class exceptions > We chose not to do these as well, and I believe that info is also in the metadocument. While I see _some_ value in having PSR-7 and PSR-17 merged, I also see value in keeping them separate. I'd like to see more justification presented before we consider walking that path. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him -- 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/CAJp_myV%3Dt-GhCfnz%3DL4L7jTjYGsPSuwrysheO97-TVT8Uq2ZKA%40mail.gmail.com.
