PSR-7: real problems at working with abstract objects

[Anton Fedonjuk]

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

[Matthew Weier O'Phinney]

On Mon, Oct 14, 2019 at 9:34 AM Anton Fedonjuk <antonf...@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
mweiero...@gmail.com
https://mwop.net/

he/him

[Anton Fedonjuk]

My package A used in other package C (created other coders): it send objects from package B (created other coders too)  to objects by package A.

As example user creates package "shop" (C) and want send sms via my package "sms"(A). Package A can use any PSR-7 package (B)  for sending requests to gateway over HTTP protocol. In this case, user cant use package B not supported PSR.

вторник, 15 октября 2019 г., 1:25:54 UTC+3 пользователь Matthew Weier O'Phinney написал:

...