Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113261 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9501 invoked from network); 25 Feb 2021 12:15:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Feb 2021 12:15:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A722D1804E3 for ; Thu, 25 Feb 2021 04:04:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 25 Feb 2021 04:04:17 -0800 (PST) Received: by mail-lf1-f52.google.com with SMTP id d24so8170398lfs.8 for ; Thu, 25 Feb 2021 04:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aKvIRmGp4E0ohDLbbSZjFltAlR0uReLoMX5gt829ly8=; b=AoYyLWFbqXkPuZyqf6H3utJLxl0anuJ2Gj4vNCQa+jtkR2psjZ9420W7SQ2+XgqGNf F7uZaPDPmhfF9LiwdBtpFLUj1x2PLNQz/l1EP6Roqcd6FX3t2w78rx5Pq+UWE2ZkGe0a oABc2qE+NpwMad/7H51+k/+nC/Xm63Iu5G8x3+Bpk3P7bk++Yjei8dXg6Vx3Whssnyxn AmHw+wjkXV8y4OnK8UB5gUXIOVeXReE81AG+8oe9mXwczX89e2Mr6SrcfhDaQ0YZlPJp 0W2wtzfodDCiUMRK0+dVXerTz80h1YVyT4/SYv1pM2XIq5k3e/fIRRHW0oRDsuNY8nbf Oy0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aKvIRmGp4E0ohDLbbSZjFltAlR0uReLoMX5gt829ly8=; b=AMR5qYu5yI6WPO1I+5+ONbW2B9hFEv9iZShkUcFS0H+WAOaL4Sk3T/z1BTB7p3ty5k o+8dgi6ImSlJNNPwejl+CuaczpHX8u+EOFvGJuyAaEbtJB76NALez0iOA7XmiKc2X0d0 Y6Vas75xHU0paEkgIsKxu6NiOydyjSneG56BTWtHlWVujSmIeatYbqIaoWl8ibq5lM+G 2v0sjrfqPn7XNzOr/vwFJtd1Bkr4hwZHPcIFL/RU21iY3W4Bb3wf4/I6+Wj33rt1PZ1r YLdz72AAzExKagRUAjUE1s8YGX+YvJmjc5JASH4+109HJKWzbMrxp3rcyNQPghMvPFvS N2Kw== X-Gm-Message-State: AOAM53200suS+JfexbPWFBtosJR4qLNoYCX29z4X9uq6cJZEgkRPOxko oAjQyLCvxleCRo2YPfKxLxe5mH/y1RhgILPBd2o= X-Google-Smtp-Source: ABdhPJyiZzTsGuY8poNcWJkiZA61PIDZs/yzIn83o0q05zDLZzixFcAwzS09RfBhLSf9qw+sUb95dnvKmEGQa2ASSD4= X-Received: by 2002:a05:6512:3090:: with SMTP id z16mr1864448lfd.44.1614254653845; Thu, 25 Feb 2021 04:04:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 25 Feb 2021 13:03:57 +0100 Message-ID: To: "Christoph M. Becker" Cc: Marco Pivetta , David Gebler , PHP internals Content-Type: multipart/alternative; boundary="00000000000038346805bc27f3ea" Subject: Re: [PHP-DEV] [VOTE] fsync function From: nikita.ppv@gmail.com (Nikita Popov) --00000000000038346805bc27f3ea Content-Type: text/plain; charset="UTF-8" On Thu, Feb 25, 2021 at 1:01 PM Christoph M. Becker wrote: > On 25.02.2021 at 12:43, Marco Pivetta wrote: > > Hey David, > > > > > > > > On Wed, Feb 24, 2021 at 6:15 PM David Gebler > 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 > >> 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 --00000000000038346805bc27f3ea--