Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113260
To: Marco Pivetta <ocramius@gmail.com>, David Gebler <davidgebler@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <CA+p1Fabcg4Xm_1WUXS=TqfwqU-cWCH9zpF63cwTON--ZjZ8YDg@mail.gmail.com>
 <CA+p1Fabwm2RnkQAYdUaDkhFVO+teZE=TwYFjQijSDrjqykSOww@mail.gmail.com>
 <CADyq6s+_kGPgBarkqmw5BJR9QiDkaQ+Dq4PcPTc=kBF+FVQdtg@mail.gmail.com>
Message-ID: <dae35ab4-fd45-1ad6-c9ff-e7feffcadcf0@gmx.de>
Date: Thu, 25 Feb 2021 13:00:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CADyq6s+_kGPgBarkqmw5BJR9QiDkaQ+Dq4PcPTc=kBF+FVQdtg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] fsync function
From: cmbecker69@gmx.de ("Christoph M. Becker")

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> wro=
te:
>
>> Voting is now open for 2 weeks on https://wiki.php.net/rfc/fsync_functi=
on
>>
>> 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 voti=
ng
>>> 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 Uni=
x
>>> systems.
>>> - Adds function fsync() on Windows with fdatasync() available as an al=
ias
>>>
>>> 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 funct=
ion
> 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.

=2D-
Christoph