Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118795 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87283 invoked from network); 11 Oct 2022 12:24:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Oct 2022 12:24:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1FA1F180538 for ; Tue, 11 Oct 2022 05:24:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15623 212.45.192.0/19 X-Spam-Virus: No X-Envelope-From: Received: from mail.gna.ch (mail.gna.ch [212.45.196.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 11 Oct 2022 05:24:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id EFD253A1DBD for ; Tue, 11 Oct 2022 14:24:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mail.gna.ch ([127.0.0.1]) by localhost (darkcity.gna.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhqQC4DwTM_O for ; Tue, 11 Oct 2022 14:24:42 +0200 (CEST) Received: from smtpclient.apple (unknown [IPv6:2a02:1210:2ea4:cf00:6076:3f0b:d:4da0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id D44823A1D7D for ; Tue, 11 Oct 2022 14:24:42 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Date: Tue, 11 Oct 2022 14:24:42 +0200 References: <5EBAAEBD-4F9E-4832-BBDD-6E67D8758490@gmail.com> To: PHP Internals In-Reply-To: <5EBAAEBD-4F9E-4832-BBDD-6E67D8758490@gmail.com> Message-ID: <29756830-87E9-468B-92B8-3D0906A2A34C@cschneid.com> X-Mailer: Apple Mail (2.3696.120.41.1.1) Subject: Re: [PHP-DEV] Experimental features From: cschneid@cschneid.com (Christian Schneider) Am 11.10.2022 um 07:09 schrieb MKS Archive : >> On Oct 10, 2022, at 8:04 PM, David Gebler = wrote: >>=20 >> This is what's bothering me. Either these "experimental" features = have >> passed RFC and will be part of the language, as you've said above, or >> they're actually experimental i.e. not finalized and implementing = behaviour >> and syntax which may be subject to change or even dropped entirely >> depending on the feedback cycle.=20 >=20 > If they are not experimental and their usage is finalized, then they = are in-fact approved and they would be absolutely no different from the = existing RFCs today. >=20 > You cannot have experimental features unless those features have the = potential to not be included in the future language and/or those = features have the potential to be improved before they are finalized. = Otherwise, what's the point? We seem to have two different views on experimental feature here: You = are saying they could get removed again while others stated it is for = stuff which will definitely end up in stable when the next major release = is done. IMHO there needs to be a consensus about this before we can continue the = discussion, otherwise we will go around in circles. >> Using the trivial json_validate() example (although as others have = said, a >> simple new function is probably a bad example),=20 >=20 > (As an aside, I disagree that a new function would be a bad example. I = think it would be a good use-case for experimental features because of = how decoupled it would be from the rest of the language, and it would = help to see if a lot of people use the function before committing to = including it.) That's another thing where we need to find an agreement first: Are we = talking new, isolated functions or are we possibly also talking about = core new language features (i.e. new syntax / semantics)? The work for maintenance by core developers could be much higher if it = is not limited to new functions. This is IMHO an important aspect as we do not want to make life even = harder for the core team. Hot take: If it is only about new functions then we don't need anything = in the core, just create an \Experimental package with poyfills and = you're done ;-) >> If it's the former, the library can just check if PHP >=3D 8.3 and = fall back >> to userland implementation / polyfill for earlier versions. This is = just >> what we have now, where approved new features are part of a versioned >> release. >=20 > Not all potentially useful functions can reasonably be implemented in = userland PHP. ... but almost all of them can. I'd go as far as saying that while emulating json_validate() using = json_decode() is slower and uses more memory it still is a valid = polyfill. It is IMHO easy enough to develop with a higher memory limit = and performance is not that critical for development either. And unless you want to ship experimental code to production (which you = shouldn't) you will have to wait for the next major PHP release anyway. - Chris