PSR-7 nor PSR-17 specify where the cursor should be positioned and I don't think it should either.
Sure, one would think it makes sense to have the pointer at the beginning of the stream because "that is why I will start reading". But that does not take middleware into consideration. A middleware that write stuff to the end of the stream would never like the cursor to be at the beginning... Other edge cases to consider are non-seekable streams or just non-rewindable? I think we should not try to amend a PSR and specify a "default behavior" because: - Since specifying a "default behavior" for this is close to impossible (just see Woody's and Rasmus' short discussion) - Neither currently PSR mention it - Thanks to Martijn research we can see that the implementations are rather spitted as well The consumer of a stream must always make sure to move the cursor before the are using a stream. (Or use __toString()) Den måndag 7 januari 2019 kl. 16:56:03 UTC+1 skrev Rasmus Schultz: > > > This does not sound like something that can just be errata’d in, and > defining behaviour now will lead to breaking changes in implementations > > I have to disagree with this assertion. > > There's no breaking change versus a previous, incorrect specification - > the problem here is a simple omission, not an error in the specification. > > The interface won't change, so this isn't a breaking change to the package > either, and should be versioned either as a bugfix (1.0.1) or a feature > (1.1.0). > > Yes, this will render some existing implementations incompatible with the > specification - that's okay, these packages will need bugfix releases, and > will then be compatible with both versions of the PSR package. > > No, you won't be able to look at the package and tell from it's > requirements whether it's been updated with regards to the corrected > specification - but that's probably okay too, as this will be a quick and > easy fix for most packages. (Packages that don't satisfy the updated > specification simply had bugs, we just didn't know before, and that's > normal - that's what bugfix releases are for.) > > I understand you strictly could make an argument that this is a breaking > change - but it's much easier and simpler for everyone to just treat this > as a bugfix. > > The only alternative is an entirely new PSR, which is much harder and > messier for all vendors and consumers involved and just sounds like a > meaningless waste of time. > > Some of the existing implementations will be rendered "buggy", but bugfix > releases will need to be published either way, and a bugfix is a much > smoother transition for everyone. Again, there's no breaking change versus > a previous specification - it's an omission, not an error. > > Lastly, it would surely be better if everyone gets these fixes > automatically with a composer update - as opposed to forcing everyone to do > the whole dependency song-and-dance just to get what is essentially a > simple bugfix. > > Let's correct this mistake and move on, please. > > On Saturday, December 29, 2018 at 1:07:31 AM UTC+1, Martijn van der Ven > 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b7fba90c-0bab-41ae-a557-bf23d19e1c47%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
