> 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/d9a5fae0-366f-4473-a8d6-138b05466cb9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
