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. -- Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
