I'm pretty sure this is a PSR-17 issue, as it deals with creation. PSR-7 does not specify constructors, so it probably shouldn't specify anything about creation.
On Saturday, December 29, 2018 at 8:34:13 PM UTC+1, Larry Garfield wrote: > > I think this may technically be a PSR-7 issue, not PSR-17, or perhaps it's > an > area that overlaps both. I ran into this issue myself when working on > ApiProblem. and it took me a while to figure out that the cursor was not > where > I expected it to be. :-) > > A SHOULD errata sounds like the right solution, I agree. What that SHOULD > should be, I'm not sure yet; I largely defer to the PSR-7/17 WGs and > Editors. > > --Larry Garfield > > On Saturday, December 29, 2018 10:31:17 AM CST Woody Gilk wrote: > > Good report, Martijn! > > > > From my perspective, it would make sense that the position would be > always > > be set to the end of the stream, as if the stream had just been written, > > mirroring the fopen(), fwrite() sequence that would normally be done. > > > > I'm not quite sure on the bylaws about level of recommendation, but an > > errata to the following would cover this: > > > > Streams SHOULD have their internal pointer set to the end of the > underlying > > resource. > > > > FIG, would having this as an errata be acceptable? > > -- > > Woody Gilk > > https://shadowhand.me > > > > > > On Fri, Dec 28, 2018 at 6:07 PM Martijn van der Ven < > > > > martijn....@gmail.com <javascript:>> wrote: > > > There seems to be some disagreement on where the file position > indicator > > > (cursor) ends up upon the creation of a Stream instance. I have done > some > > > minor testing and put the results on GitHub > > > <https://github.com/Zegnat/php-psr17-test-cursor>. This can lead to > > > incompatibilities when doing something like: > > > > > > echo (new StreamFactory)->createStream('Hello!')->read(6); > > > > > > - createStream() seems to be the most contested. The cursor goes at > > > the start or end of the string. Even more surprising (to me) is > that > > > Diactoros will result in a different state depending on whether you > use > > > its > > > own factory or the tuupola one. (Again showing how compatibility > may be > > > an > > > issue here!) > > > - createStreamFromResource() seems to be agreed upon by all > > > implementations: keep the cursor wherever it was at in the original > > > resource. Even without specifically being defined by the PSR this > makes > > > a > > > lot of sense to me, and I will propose adding a test for this to > the > > > (official) unit tests. > > > - createStreamFromFile() has one of the tested implementations do > its > > > own thing: berlioz/http-message copies the contents of the file > into a > > > new > > > stream and puts the cursor at the end. Every other implementations > puts > > > the > > > cursor at the start, matching where it would be if fopen() is > called on > > > a > > > file. > > > > > > Of course the (official) unit tests > > > <https://github.com/http-interop/http-factory-tests> that go with the > > > PSR-17 interfaces do not have tests for any of this as it isn’t > covered by > > > the PSR itself. > > > > > > The default for createStream() is a coin toss to me. I see no clear > > > argument for either position. But I do think the PSR should define a > > > location. This does not sound like something that can just be errata’d > in, > > > and defining behaviour now will lead to breaking changes in > > > implementations > > > > > > :( Not sure what the way is to start addressing this. > > > > > > For *FromResource() there seem to be good reasons to just leave the > cursor > > > be where it is, and I believe this can be mentioned by the PSR. As all > > > implementations do this already, maybe this can be an errata of some > kind? > > > > > > For *FromFile() I don’t know what can be defined, other than saying it > > > should follow what fopen() does by default. For files this will mean > the > > > cursor position is set to the start of the stream, I am not sure what > the > > > cursor does for other protocols/wrappers/schemes. > > > > > > Ideas? -- 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 post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/e6032c95-61d6-4aa6-bedf-f3b439208c09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
