Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117678 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 19686 invoked from network); 6 May 2022 20:39:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 May 2022 20:39:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E9694180053 for ; Fri, 6 May 2022 15:16:52 -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=0.6 required=5.0 tests=BAYES_50,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-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (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 ; Fri, 6 May 2022 15:16:49 -0700 (PDT) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-2f7c424c66cso95884407b3.1 for ; Fri, 06 May 2022 15:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=cIyBk51yLBpZ+QDLzSLDEE3P25ioMHnLrgCtahy7HCU=; b=UCGw/dN5ECQqLJEbu6A3mANpPWR2lVaEliVI5s8tie44HZ5VAHMwdKyDCb6FTlgUzK fmh2XWEq6mhAP0n0/qzUbgY5E2uheaBCUmZjPRVNqr8PXROZPElxu+YIbOUFAJlYhmLu gMnnNWvRUltNGUeEjnxD++wglbSDvIujVS6RZ/ujTW3UUm4sLaQ+0Q1TgPoi829QbVQB vrdYIBYSh4nl1VgfnfIYGOnZreImu3nEUIIitGd/GwhkrmPw5x+qqXAU3IXcA7LcRBjO b8o8LRWYUrFJtdWAi48SGfYCNMehAHy/cuZddpOmRv0WAcubO0RfvoNEUzGfqlFIMKXm 8yvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cIyBk51yLBpZ+QDLzSLDEE3P25ioMHnLrgCtahy7HCU=; b=0YWZkZ6Q1AZlM6r3nFWk9LsmHtuwb9gh2nCP6k6snQmWgGwDkzV1QXAlUhQ1Mz5HDc 53IzaFRaHbUae2wvbSPcZvkluI+DDVl8GBDQRhCPVEce7A6XQtKzbjWQdcASmpO+3s28 We3mZQmAyf6s3q+AC/yEDOwChCxNrEA1uDU4qwhsYh169kJZXJzPJ10eLS7W77AOMEvq H9hsKyDY47TZD5nUXeQ4UIGYpVIEGLbsAs3TrsMl4QTFyUbfLTP+irD+pkn5gotTuYWN nUhwk8qkK2io0hIXoPC0CrWhJXDuVXjA3nf+66D0akr23PW+ZpTs3NxDM0elixyPvpvI JMeQ== X-Gm-Message-State: AOAM530iQ3hQ9pS6CG+tk9IkvbRT3DUJgpJM27Qa8OPNyi1L7rL0LnPJ qhn86RiTAGNeETgEhDm/AGeVSEh3sR86OwJLP7hPU/gn13c= X-Google-Smtp-Source: ABdhPJzqYyqg580erTTwsvwVXLzhSkB5Lca598WeHrP3Io2WerxkgP+rHY0GyCLB7woVjGfrbvy8FqDDXjWjcmXJhAM= X-Received: by 2002:a81:618b:0:b0:2db:d952:8a39 with SMTP id v133-20020a81618b000000b002dbd9528a39mr4587159ywb.132.1651875408554; Fri, 06 May 2022 15:16:48 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 6 May 2022 15:16:37 -0700 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000f0b0c705de5f3620" Subject: The future of objects and operators From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000f0b0c705de5f3620 Content-Type: text/plain; charset="UTF-8" Hello all, I took a while away after my operator overload RFC was declined. I've been mulling for the last few months how to move forward while respecting the concerns and feedback of those who abstained and those who voted against. But I feel like a separate discussion needs to happen first after considering many different approaches. # There is Considerable Demand For Improved Control of Operators with Objects This doesn't apply to all operators. I have not seen any comments in the last few months of digging of people who are desperate for the pow operator ( ** ) for instance. However, many people who work with math in PHP have use for at least the arithmetic operators and I see this comment frequently. Totally separate from the math domain, I've seen many comments about the desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This is something that would have numerous applications outside of mathematics, and there's even been an RFC worked on (that was declined in 2018) by Rudi to implement just comparisons. # Different Voters Have Different Concerns This is an issue that almost all RFC authors must deal with of course, but this particular subject suffers from it more severely than most. For instance, in some of the past proposals that were more limited than mine, there were comments that a full operator overloading solution should be provided instead of something halfway. However one of the comments I received more than once was that I should separate out the comparison operators into its own RFC, since those have applications outside the math domain. # Is Math A Valid Use Case? One of the more shocking (to me personally) pieces of feedback that I received from more than one person is that math is not a valid use case in PHP. I am... unsure about what to think of this opinion. I guess I would like to discuss and find out if this is widely believed among voters. # Non-Breaking Engine Changes The way that equality and comparison evaluation is done in the engine makes it impossible for certain kinds of overloading to be done, even in extensions. This isn't because that was an intended restriction, I discussed this issue with CMB and provided a PR a few months ago to resolve this, however it has remained in limbo: https://github.com/php/php-src/pull/7973 # Overall Vision I'm not sure at this point how voters think objects and operators should work together into the future. I'd like to see if anyone is willing to have high-level discussion about the ideas, instead of picking at the implementation or details of a particular RFC. Jordan --000000000000f0b0c705de5f3620--