Revising, `$class = get_class($body_stream); new $class($string)` would be incorrect (depending in implementation of StreamInterface)
On Tuesday, July 6, 2021 at 4:47:05 PM UTC-7 Adam Frederick wrote: > specifically NOT force the idea that content MUST be a string >> > What I presented is not advocating forcing the idea that body must be a > string. In most cases, it is a string of text, and in all cases, it can be > a string (although not very useful to have a binary stream turned in to a > string - but who would do that). I would imagine most HTTP middleware in > php is dealing with bodies as strings. You did make a good point on > discord, however, that `withBodyString()` would force the response object > to know how to create a stream from the string. I don't think this is so > problematic, however, since it already knows about the stream and the > stream class, It would essentially have to do $class = > get_class($body_stream); new $class($string); for the withBodyString > function. And yes, the middleware could also do this, but that is not > immediately obvious to middleware makers. > >> >> We deliberately chose not to have any of the PSR-17 interfaces extend >> from the others. The reason is that there were too many combinations, and >> most times, you only need 1, 2, or 3 capabilities, making it relatively >> easy to compose them into your classes via dependency injection. If you >> find yourself needing multiple capabilities regularly, create your own >> interface that extends the set of interfaces you use regularly, and >> type-hint on that in your middleware or handlers. >> > > Right, it can be done. That's not my issue. My issue is that it is not > standardized. Again, doing it the way you are mentioning relies on the > non-standard that whatever is using my middleware resolves the interface > dependency. > I agree that it make sense to separate the factories as different > interfaces. But implementations will combine them because the separation > is unnecessary ( > https://github.com/Nyholm/psr7/blob/master/src/Factory/Psr17Factory.php) > > >> >>> 2. Middleware constructor interface dependencies should be resolved, >>> allowing injection of factories. >>> Combined, the ServerRequestInterface could just inject itself wherever a >>> PSR 17 factory was required. However, #2 puts the demand of interface >>> dependency injection the the implementer. >>> >> >> Constructors cannot be specified in interfaces. Well, they can, but PHP >> does not require implementations to honor them. >> > Not what I meant by "constructor interface dependencies". I meant > __construct(RequestFactoryInterface $request){}, where you then rely on > injection that resolves the implementation of the interface. > >> >> But the fact that PHP won't do it, and it would preclude having custom >> constructors, means it's simply not an option. >> >> >>> >>> Without a standard, constructing middleware relies on knowing what the >>> framework will do. If the assumption is that middleware will have the >>> factories injected, this should be stated in the standard as the standard. >>> >> >> There are no assumptions. >> >> You can instantiate a response, URI, stream, etc. directly in your >> middleware. (and thus tie yourself to a specific implementation) >> >> Or you could inject factories, and use the factories to create the >> instances. >> >> It's up to you as a developer to define what your class needs to do its >> work. PSR-7, PSR-15, and PSR-17 are very loosely coupled to allow exactly >> this. >> > > Right, so there are two non-standardized options. > 1. use dependency injection and rely on the framework injecting the > dependencies > 2. create my own set of package requirements for my middleware. The > problem with this being the potential for there being 20 PSR 17 > implementations, and various middleware all requiring their own. > > My thoughts on the matter are about allowing the writer of middleware to > have a standardized mechanism for accessing PSR 17 factories. If > dependency injection should be the standard, then standardize it. > > But, I think an easier mechanism would be to have an > extended RequestHandlerInterface that implements the factories. "PSR 21 > ExtendedRequestHandlerInterface implements ...." > > Think about, as a framework, explaining this to middleware developers. > You either end up explaining: > "in your __constructor, make sure to have the various factory parameters > that you need, and then assign them to properties of your object so you can > use them in your process method. We will inject the dependencies as you > need them." > Or you tell them > "you can create a stream by doing $handle->createStream()" > > What ends up creating more standardized code? > > > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5ad77e0f-86af-4040-aa40-864961d73cf9n%40googlegroups.com.
