Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118791 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 48978 invoked from network); 11 Oct 2022 00:05:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Oct 2022 00:05:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 459AC1804BC for ; Mon, 10 Oct 2022 17:05:10 -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=-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, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 ; Mon, 10 Oct 2022 17:05:09 -0700 (PDT) Received: by mail-wm1-f43.google.com with SMTP id o20-20020a05600c4fd400b003b4a516c479so7233231wmq.1 for ; Mon, 10 Oct 2022 17:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5b/A1lKCbAtvtZeivfEgH3U7FXtpm0dOsP7QmMPU2Gw=; b=EfYLk7t8Xq6qwHibLANZm3hOUkx7ppz5txlZbo2RZeH0CfQnrOUbyuo7vdbW8EBBrs beCt9TX4ZOxfV8jjZGBx3cWE0wALlib80kObG1IS2aaLFsf6IHG67XIYGRnEenPE2Hzp SaOob9EIUFHJ0vEmez0wBrwI+LUFth++sODrDp4UTlo8Ls+ma2p934BqoBAlKNFI39PI 5b57BlMKmlpnCzCG07ctXbQZpIcJys44EtODVex4iE7nXIMevSy0ouvEdOIWByiU5PKk 4o9vcKzQvlTWXI45fLRy82aTDvWw+NbaJABmFS/+SDYkptUylXcSCfeBQpbeqoLqkpB2 ie7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5b/A1lKCbAtvtZeivfEgH3U7FXtpm0dOsP7QmMPU2Gw=; b=USdstUWsJXy9eGcbuMFsjBA6mVrtJnM2jVMayEOnNgy5P2iIEZ+MceALiU+iCS5Hq9 tn34WQmjIt5C5Y5gMgCaTIFHIKlVBucq2+oCIRk08sOVQdRiuV9uwkKztfr94uImTDwD M9iOs2YPc9//GE9afKEtVldKnGBfSC8BHMcM2r0d2T4sG7zMMxp2TS6RY2F4ZcJk9OF3 D5Yr4gQpVaAnwHZiPK5ovqPpdnDdW1gah3awpqRh5T6V/dGtPotjOh+3MFyCsNg7Mye2 x4ZH1GmHH/kY+9MJ/7cSnBV9ASuU1X0h8Z9K7/FSHcuHTXnsIaodH6rrWXfs2OsxcDJB 0Zig== X-Gm-Message-State: ACrzQf3aSIaDP7jzyV4dGJ0ZwbJLMdxtVHYhSjBGZ/PWbgatJhr+Yj0Z e3+UPE5B/j6jg64kVG7kAwEcBAjHsm1qAg8bC18= X-Google-Smtp-Source: AMsMyM4SKQBm/Z1bKajHa4QeAN25S1HpK/fXxussXk/WmbjvmQalgvGxOxGSIxXP6umcMLr5LBo0OlTDJNsZiZboex8= X-Received: by 2002:a05:600c:1da2:b0:3b4:856a:162c with SMTP id p34-20020a05600c1da200b003b4856a162cmr20819712wms.28.1665446708387; Mon, 10 Oct 2022 17:05:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 11 Oct 2022 01:04:57 +0100 Message-ID: To: David Rodrigues Cc: PHP Internals Content-Type: multipart/alternative; boundary="00000000000072243605eab7074a" Subject: Re: [PHP-DEV] Experimental features From: davidgebler@gmail.com (David Gebler) --00000000000072243605eab7074a Content-Type: text/plain; charset="UTF-8" On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues wrote: > The idea is that the experimental features are exclusively something that > the PHP team has voted for (approved) and that will be part of the language. > So they're not experimental features, they're accepted RFCs, maybe with a lower voting threshold. > Imagine a package under development (eg. Laravel 10) that is (supposing > that) intended to be released compatible with PHP 8.3 (supposing that it > already has experimental features). In this case, the Laravel team can > start using an experimental feature while developing Laravel 10, waiting > for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel > 10 can just remove the experimental tags and release its new version fastly. > > The user, on condition that he is willing to use Laravel 10 (in > development) will make indirect use of experimental features. Then both the > Laravel team and these users will be able to provide feedback for these > features to the PHP team before the official release. > > Like json_validate(): assuming Laravel needs to check if a code is valid > JSON, but without processing its data for use. It could check if PHP >= > 8.3, so use experimental_json_validate(), else use previous PHP compatible > code. > 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. In which case, they cannot be relied on by developers of vendor packages or their users in the manner you suggest. Using the trivial json_validate() example (although as others have said, a simple new function is probably a bad example), either this function will be part of PHP 8.3, with the exact behaviour, parameters and return type which is known and documented, or it's experimental and might change. If it's the former, the library can just check if PHP >= 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. If it's the latter, everyone touching the experimental version, directly or indirectly, may have to rip out and change code later which renders the work they've put in to use the experimental feature in their code pointless. And it's not just how these things may or may not be used by users of the language, it's how building out this system affects the clarity and maintainability of php-src, which is esoteric enough as it is. I can appreciate and support specific individual new, accepted features which may not be 100% stable having a toggle in the configuration, but I'm not convinced on the justification for a broader system of introducing unstable features which are toggled at the syntax level. On Tue, Oct 11, 2022 at 12:06 AM Mike Schinkel wrote: > A lot of developers (most?) who build PHP applications run them in > shared-hosted or managed hosted servers where are never given the option to > install a PECL extension. In the rare cases they can install PECL many of those PHP developers would > not have the skills to do it or the requisite permissions on the server; I > certainly did not for the first ~10 years of working with PHP. I do now, > but ironically because I have mostly moved away from programming in PHP to > do more DevOps work. > > Further, when working in multiple environments having to set up each > server to have all the same PECL installations can be just too much hurdle > so that developers won't even try, especially when working in managed > environments. > > I'm inclined to suggest if you opt in to an experimental language feature, you are by definition making at least an implicit declaration that you know what you're doing, so the idea people using these features wouldn't have the skills to spin up a container or install something on a VM doesn't convince me, personally. --00000000000072243605eab7074a--