Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118752 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 40257 invoked from network); 5 Oct 2022 13:38:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Oct 2022 13:38:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EA2541804BA for ; Wed, 5 Oct 2022 06:38:34 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,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-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (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 ; Wed, 5 Oct 2022 06:38:31 -0700 (PDT) Received: by mail-pg1-f172.google.com with SMTP id 78so15254952pgb.13 for ; Wed, 05 Oct 2022 06:38:31 -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:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=b92wF2X5fh1HJ4/7h2abE5b1bkOHx1FEzDHeVTAldtQ=; b=TV8WLi+JVv942AqkvdCU24IDulfQDm2PywZZqOCagYFVloZ+PvRgl84sVZBEfj8l1F /ZEpfq1xFQOCW76jbLx6+Ku65jC6EPYvQNIWABEa8PMybJl/r0vJZF4FfYyRhgpi6QXX 1q9OYAlgWw4J9IijaUftopE/bU/HnFLw8Gx3v4E0E1b9aqDV1wFbQJdMe3Mmjz7O9MQ5 gNbEsMOMVO+yqW36UgUQb0B2gf9wEwd74jQMcZS79GPYR/U34ucagAhZJxv1e2MXdPEI hyJZmt29Y/deI9C1g/eK6uiDPAilnzioqo5d7arFk4qWrY7Xyr1DEKRtzmpp1TphFQT9 lJTg== 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:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=b92wF2X5fh1HJ4/7h2abE5b1bkOHx1FEzDHeVTAldtQ=; b=mkQDS78UrVtOwquob51eKEI5kykIJ49lBYSvibtVglWp2aOSa7qL4Be75IaJ+lxzYE gC7Ac2uNxZnuvFrDpcPJdOEh6g+eZFO/t7Hi8g80fC7ggJ3x0MioagwqHr7f5vCm9oZ6 jgE7m8Nu9PuR/n6dKo2Ge4MwZlPZ8I+xhQL3FLag/hd0c3N8GszsZPUimdhKwueWozlD lJ6N+3ce0qhKQpGFY/GLPgne/EOFVUFnGKJoc2/adfq+Wp8XIJvvI9vDD6C5NzUsNX/H 4fw0DRcDvsNVqjQ4zzxghQlpOeKy/1fNLPReqo4O8aznu8KhXXbBQHBsWW1L5C6YHMva iO7g== X-Gm-Message-State: ACrzQf2V/PCSWkiQUfdTn6dMbFe54aUmeEpri+B5ZDWWcbVF1NCsBLn2 EdJiYTpPlo/VdtgSvaFOfoHPhyRa7DmALDu+yuHk4jLMkzL8CA== X-Google-Smtp-Source: AMsMyM4PQwnCFki0Mx4afqJQ1vk7ja428kFggyNhDM0pv9JMsEc5CJ9i7GEFnpXkgs32Vvmr71qRNP/ql6ZNTvwtxyg= X-Received: by 2002:a65:6e9a:0:b0:435:6009:4b62 with SMTP id bm26-20020a656e9a000000b0043560094b62mr28062916pgb.596.1664977109925; Wed, 05 Oct 2022 06:38:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: autaut03@gmail.com Date: Wed, 5 Oct 2022 16:38:17 +0300 Message-ID: To: =?UTF-8?Q?Fl=C3=A1vio_Heleno?= Cc: David Rodrigues , PHP Internals Content-Type: multipart/alternative; boundary="00000000000032439b05ea49b191" Subject: Re: [PHP-DEV] Experimental features From: autaut03@gmail.com (Alex Wells) --00000000000032439b05ea49b191 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey. Experimental features have been briefly discussed before in https://github.com/PHPGenerics/php-generics-rfc/issues/49. I believe this is a good starting point to understand how it's different to extensions or otherwise different builds of PHP. Advantages of experimental features over extensions: - they allow changes to the parser - they are universally supported (by IDE's, parsers etc) because they are part of a stable language release, not an unpopular/unknown extension - usages of them can be found in a codebase and then analysed (unlike extensions that don't have any kind of marker to denote them from regular code) - it's easy to implement a universal warning mechanism - for IDEs, static analysers and PHP itself to warn users about the consequences of using an experimental feature - they don't need a versioning mechanism, because they are effectively always "alpha" - i.e. non-stable, so any PHP release can introduce a breaking change into an experimental feature On Wed, Oct 5, 2022 at 1:38 AM Fl=C3=A1vio Heleno wrote: > On Tue, Oct 4, 2022, 17:43 David Rodrigues wrote= : > > > I wanted to suggest the possibility of introducing experimental feature= s > to > > PHP. > > > > This is an old thread I guess, but I think it's good to reevaluate the > > situation from time to time, as other languages already do this to some > > extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and > > libraries (React) bring features natively in an experimental way. > > > > I wanted to propose that we bring this idea into PHP, so we wouldn't ha= ve > > to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out > these > > new features, and so when these versions arrive, they'll already be qui= te > > polished, avoiding patches sometime later due to wider usage of users. > > > > My idea is to have two levels of experimental features: > > > > (1) Via declare(), when the feature affects how PHP can act when readin= g > > the file itself. Eg. declare(experimental_operator_override =3D > > true), Something that happens with Kotlin, for example, when we use som= e > > experimental annotations like contracts. These declarations work "per > > file", so whenever it is necessary to use it, it must be declared. > > > > (2) Via experimental identifier name. Eg. experimental_json_validate() = or > > Experimental::json_validate(), like in Kotlin and also in React. > > > > Experimental features can only be brought into a minor version (eg. PHP > > 8.1.12) when it is minimally refined and practically ready to use. It > would > > be "kind of" an expected final version, no new patches are expected (we > > hope), unless something really went unnoticed. > > > > Despite this, experimental features may not exist until the next > > major/minor release if its practical inefficiency is found or if the > > concept is shown to be invalid. So it should always be a "use with care= ". > > > > However, if an experimental feature is successful, it becomes final at > the > > next major/minor or major/minor+1. The experimental version becomes an > > alias during some future versions until it is removed entirely. This is > the > > time for users to adapt their code and for IDEs to help us find them. > > > > With this, we can understand whether users are making use of a certain > > feature or not, make improvements on it, etc. > > > > I notice that many good features are rejected because they are believed > to > > be bad for PHP or can be confusing, but without any practical testing. > > Experimental features can make this analysis more grounded in practical > > data than just possibilities. > > > > However, this also doesn't mean that any idea can become an experimenta= l > > feature, but ideas that have a good foundation and a good discussion > before > > it. The difference is that the feature can be tested in practice before > > being totally rejected, and approved features can be delivered ahead of > > time to refine before the next version is released, allowing users to t= ry > > them out more easily. > > > > > > Atenciosamente, > > David Rodrigues > > > > Hi David, > > Could this be done through extensions instead of having to develop a new > process/support code? > > When json support was first introduced into php, it was done as an > extension and then, after a while, incorporated into the core. > --00000000000032439b05ea49b191--