On Thu, Feb 25, 2021 at 1:01 PM Christoph M. Becker <cmbecke...@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 <davidgeb...@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 <davidgeb...@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. Regards, Nikita
