[VOTE] fsync function

> On Thu, Feb 25, 2021 at 1:01 PM Christoph M. Becker <cmbecker69@gmx.de> > wrote: > >> On 25.02.2021 at 12:43, Marco Pivetta wrote: >>> Hey David, >>> <http://ocramius.github.com/> >>> >>> >>> On Wed, Feb 24, 2021 at 6:15 PM David Gebler <davidgebler@gmail.com> >> wrote: >>> >>>> Voting is now open for 2 weeks on >> https://wiki.php.net/rfc/fsync_function >>>> >>>> Regards, >>>> David Gebler >>>> >>>> On Tue, Feb 23, 2021 at 5:15 PM David Gebler <davidgebler@gmail.com> >>>> wrote: >>>> >>>>> Hi internals, >>>>> As there appear to be no objections or concerns, I intend to open >> voting >>>>> on https://wiki.php.net/rfc/fsync_function tomorrow and voting will >>>>> remain open for two weeks. >>>>> >>>>> The RFC and its implementation >>>>> >>>>> - Adds functions fsync() and fdatasync() for plain file streams on Unix >>>>> systems. >>>>> - Adds function fsync() on Windows with fdatasync() available as an >> alias >>>>> >>>>> PR ref https://github.com/php/php-src/pull/6650 >>>> >>> >>> Just clarifying on my "NO" vote: I'm opposed to having more E_WARNING >>> raised by the language. >>> >>> We have better approaches for that: >>> >>> * exceptions >>> * union types >>> * Maybe/Either types >>> >>> I don't see a reason to introduce a warning here, and it makes the >> function >>> unusable unless some poor soul implements a library that gets rid of the >>> warning. >> >> Note that *this* warning is never supposed to occur in production, >> because it is a programming error to pass a wrong resource *type*. >> Rasing a warning for wrong resource types is standard behavior of >> zend_fetch_resource() (unless no resource type name is passed). I don't >> see why these new functions should use a non standard mechanism. >> >> Of course, in the long run resources should go away, which would resolve >> this issue for these functions as well. >> > > A wrong resource type will throw a TypeError as usual -- the warning is > thrown if the resource is of the correct type (stream), but does not > support sync operations. For example, if you tried to do an fsync on an > http:// stream.

> Throwing a warning in such a case is consistent with how functions for > other optional stream operations work.

> > Throwing a warning in such a case is consistent with how functions for > other optional stream operations work. >