> > 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/2b54936e-cd56-4255-abad-81da904d3fc4n%40googlegroups.com.
