Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125550 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 79FAA1A00BD for ; Sat, 14 Sep 2024 21:48:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726350628; bh=AbwfLq9zBONzkuY9ThSoKq8uPnc32Qielesj05k1gFY=; h=From:Date:Subject:To:From; b=X5xuXyV0YnfM0e8oWaPBiDNL+zy+99EaF1uhaLPAecB2C6oLiQvtAHvUWMqAOJPi/ bvKinIDOZ8nt5HJnRCnJ6xMCRMNyUd5hAL3TuEjQuAhFe1UCnuwZiuU4jCWqIR3u5U IGVaJ1hdHVaxICykYnXGWHqwU00hEiCINzbMkRSdd/CovHZYOLKIA6FCUSDF3uT5xM 2UhpIBhefSyMMxmzV68R3gNmAEX0ifpyXoL9b3drKNx1mDwfI8Fu+o8Wdc1sRLB7kQ /Isthfq0BFt3objCex6LahLkXbnjDVPYIZX3K+Wb+LiLPqAGQZIecMfpVQImAxSq36 /L+8jUFO7v4eA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 140C318007A for ; Sat, 14 Sep 2024 21:50:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-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,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_KAM_HTML_FONT_INVALID autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 14 Sep 2024 21:50:27 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-2d877dab61fso1463917a91.3 for ; Sat, 14 Sep 2024 14:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726350503; x=1726955303; darn=lists.php.net; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=AbwfLq9zBONzkuY9ThSoKq8uPnc32Qielesj05k1gFY=; b=LTu9wx4D19uEFv+BchPhBTCyG+8mz3v2kjF/giHu4jqu8Ha28fGxRIiwJw1/PxoHYB K3Jt7Tqm7sUcVdXZBw8U1lK+1/UTSQjAcV+JDfgsEQzloDPsuDTDtC5ICHzb08egPXOc rsa/nVzQb4NUZ7ZnPBtNO+YplLS9kfQGQa1HIJJmNU6/mnB1tfRhipOFe7rFSWoWCwrg F13eMWUMmwaXq6m8Y35kwXkXU3qOqvcSVbNgFEZ3ommlrOesuXPU1tSsYgZYdQ7v+pjV 4kvVFjPBZsn54Mqt46ifD1xSV3fezAUaUeBDpWCZ+yJmeZ5k8nQgHDMrygEXqbuZHyo6 yKdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726350503; x=1726955303; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AbwfLq9zBONzkuY9ThSoKq8uPnc32Qielesj05k1gFY=; b=KNlUJbUxnqkU9+oaQsQsf8o8jS1WhRffbEcQiTPGpJw00bkaQnaXMx/edRkS9G1yLu S99Ovec2coXRGj2JaFWfMCn3O2eSirWYQrVAZuCyTPMN5F7kyM59E2A+OIYjS0jS/VZm SMB2aIkb+ygkZkhYLL81Tupr/DCpnTpov6lm1fFxnuq0pZ0JYGz9K+NWXrUgCN6mLD7J mOoUV0bTN33NWReF0XnwmMJSMT4BMCHclxIkpWV8CxqRYPt27JFCVZqyooIO8fxmJ3Bh aVBrzxSUhTkwUueo5R5j/lX0/H4XcDa7WcR5JAXPtAZMkmfR+cWPPtQkOKoz2O5G+Leb SvfQ== X-Gm-Message-State: AOJu0YwktFiIMqAgYyZLhjyu7X1AR2DNYUtNelXFyJzaiJa3sh9WXATE nV8hdIB0sjW/FWRkb1quavy5gjpo9SRAKKdiUcqCT/kY1HOav6FWBHo7IOxozQeAE7UY/YJf27t StAp/pMQbbVt7usSAQSqMWCamwGM+deDY X-Google-Smtp-Source: AGHT+IGB6WeAvSEA12sP0NPcVzN1+BMGt4TIOPFoEZ3Y0JqDstV1s/Fno3608kBuJ8BjrTKLwKhbKf9hkkm9QNomK7U= X-Received: by 2002:a17:90b:1c8c:b0:2d8:f99d:48d2 with SMTP id 98e67ed59e1d1-2dbb9edd763mr10843074a91.29.1726350502405; Sat, 14 Sep 2024 14:48:22 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Sat, 14 Sep 2024 14:48:11 -0700 Message-ID: Subject: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again) To: PHP internals Content-Type: multipart/alternative; boundary="00000000000074313c06221b4cef" From: jordan.ledoux@gmail.com (Jordan LeDoux) --00000000000074313c06221b4cef Content-Type: text/plain; charset="UTF-8" Hello internals, This discussion will use my previous RFC as the starting point for conversation: https://wiki.php.net/rfc/user_defined_operator_overloads There has been discussion on list recently about revisiting the topic of operator overloads after the previous effort which I proposed was declined. There are a variety of reasons, I think, this is being discussed, both on list and off list. 1. As time has gone on, more people have come forward with use cases. Often they are use cases that have been mentioned before, but it has become more clear that these use cases are more common than was suggested previously. 2. Several voters, contributors, and participants have had more time (years now) to investigate and research some of the related issues, which naturally leads to changes in opinion or perspective. 3. PHP has considered and been receptive toward several RFCs since my original proposal which update the style of PHP in ways which are congruent with the KIND of language that has operator overloads. I mentioned recently that I would not participate in another operator overload RFC unless I felt that the views of internals had become more receptive to the topic, and after some discussion with several people off-list, I feel that it is at least worth discussing for the next version. Operator overloads has come up as a missing feature in several discussions on list since the previous proposal was declined. This includes: [RFC] [Discussion] Support object type in BCMath [1] Native decimal scalar support and object types in BcMath [2] Custom object equality [3] pipes, scalar objects and on? [4] [RFC][Discussion] Object can be declared falsifiable [5] The request to support comparison operators (>, >=, ==, !=, <=, <, <=>) has come up more frequently, but particularly in discussion around linear algebra, arbitrary precision mathematics, and dimensional numbers (such as currency or time), the rest of the operators have also come up. Typically, these use cases are themselves very niche, but the capabilities operator overloads enable would be much more widely used. From discussion on list, it seems likely that very few libraries would need to implement operator overloads, but the libraries that do would be well used and thus MANY devs would be consumers of operator overloads. I want to discuss what changes to the previous proposal people would be seeking, and why. The most contentious design choice of the previous proposal was undoubtedly the `operator` keyword and the decision to make operator overload implementations distinct from normal magic methods. For some of the voters who voted yes on the previous RFC, this was a "killer feature" of the proposal, while for some of the voters who voted no it was the primary reason they were against the feature. There are also several technical and tangentially related items that are being worked on that would be necessary for operator overloads (and were originally included in my implementation of the previous RFC). This includes: 1. Adding a new opcode for LARGER and LARGER_OR_EQUAL so that operand position can be preserved during ALL comparisons. 2. Updating ZEND_UNCOMPARABLE such that it has a value other than -1, 0, or 1 which are typically reserved during an ordering comparison. 3. Allowing values to be equatable without also being orderable (such as with matrices, or complex numbers). These changes could and should be provided independent of operator overloads. Gina has been working on a separate RFC which would cover all three of these issues. You can view the work-in-progress on that RFC here: https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md I hope to start off this discussion productively and work towards improving the previous proposal into something that voters are willing to pass. To do that, I think these are the things that need to be discussed in this thread: 1. Should the next version of this RFC use the `operator` keyword, or should that approach be abandoned for something more familiar? Why do you feel that way? 2. Should the capability to overload comparison operators be provided in the same RFC, or would it be better to separate that into its own RFC? Why do you feel that way? 3. Do you feel there were any glaring design weaknesses in the previous RFC that should be addressed before it is re-proposed? 4. Do you feel that there is ANY design, version, or implementation of operator overloads possible that you would support and be in favor of, regardless of whether it matches the approach taken previously? If so, can you describe any of the core ideas you feel are most important? Jordan External Links: [1]: https://externals.io/message/122735 [2]: https://externals.io/message/122994 [3]: https://externals.io/message/121387 [4]: https://externals.io/message/120822 [5]: https://externals.io/message/118971 --00000000000074313c06221b4cef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello= internals,


This discussion will use my previous RFC as the = starting point for conversation: https://wiki.php.net/rfc/user_defined_operator_overloads=


There has been discussion on list recently about revisiting the to= pic of operator overloads after the previous effort which I proposed was de= clined. There are a variety of reasons, I think, this is being discussed, b= oth on list and off list.


1. As time has gone on, more peopl= e have come forward with use cases. Often they are use cases that have been= mentioned before, but it has become more clear that these use cases are mo= re common than was suggested previously.

2. Several voters, cont= ributors, and participants have had more time (years now) to investigate an= d research some of the related issues, which naturally leads to changes in = opinion or perspective.

3. PHP has considered and been receptive= toward several RFCs since my original proposal which update the style of P= HP in ways which are congruent with the KIND of language that has operator = overloads.


I mentioned recently that I would not participate= in another operator overload RFC unless I felt that the views of internals= had become more receptive to the topic, and after some discussion with sev= eral people off-list, I feel that it is at least worth discussing for the n= ext version.


Operator overloads has come up as a missing fea= ture in several discussions on list since the previous proposal was decline= d. This includes:


[RFC] [Discussion] Support object type in = BCMath [1]

Native decimal scalar support and object types in BcM= ath [2]

Custom object equality [3]

pipes, scalar obje= cts and on? [4]

[RFC][Discussion] Object can be declared falsifi= able [5]


The request to support comparison operators (>, = >=3D, =3D=3D, !=3D, <=3D, <, <=3D>) has come up more frequen= tly, but particularly in discussion around linear algebra, arbitrary precis= ion mathematics, and dimensional numbers (such as currency or time), the re= st of the operators have also come up.


Typically, these us= e cases are themselves very niche, but the capabilities operator overloads = enable would be much more widely used. From discussion on list, it seems li= kely that very few libraries would need to implement operator overloads, bu= t the libraries that do would be well used and thus MANY devs would be cons= umers of operator overloads.


I want to discuss what changes = to the previous proposal people would be seeking, and why. The most content= ious design choice of the previous proposal was undoubtedly the `operator` = keyword and the decision to make operator overload implementations distinct= from normal magic methods. For some of the voters who voted yes on the pre= vious RFC, this was a "killer feature" of the proposal, while for= some of the voters who voted no it was the primary reason they were agains= t the feature.


There are also several technical and tangenti= ally related items that are being worked on that would be necessary for ope= rator overloads (and were originally included in my implementation of the p= revious RFC). This includes:


1. Adding a new opcode for LARG= ER and LARGER_OR_EQUAL so that operand position can be preserved during ALL= comparisons.

2. Updating ZEND_UNCOMPARABLE such that it has a v= alue other than -1, 0, or 1 which are typically reserved during an ordering= comparison.

3. Allowing values to be equatable without also bei= ng orderable (such as with matrices, or complex numbers).


Th= ese changes could and should be provided independent of operator overloads.= Gina has been working on a separate RFC which would cover all three of the= se issues. You can view the work-in-progress on that RFC here: https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-s= emantics.md


I hope to start off this discussion producti= vely and work towards improving the previous proposal into something that v= oters are willing to pass. To do that, I think these are the things that ne= ed to be discussed in this thread:


1. Should the n= ext version of this RFC use the `operator` keyword, or should that approach= be abandoned for something more familiar? Why do you feel that way?=

2. Should the capability to overload comparison operators be= provided in the same RFC, or would it be better to separate that into its = own RFC? Why do you feel that way?

3. Do you feel ther= e were any glaring design weaknesses in the previous RFC that should be add= ressed before it is re-proposed?

4. Do you feel that t= here is ANY design, version, or implementation of operator overloads possib= le that you would support and be in favor of, regardless of whether it matc= hes the approach taken previously? If so, can you describe any of the core = ideas you feel are most important?


Jordan

External Links:

[1]: https://externals.io/message/122735

[2]: https://externals.io/message/122994

[3]: https://e= xternals.io/message/121387

[4]: https://externals.io/message/120822

[5]:= https://externals.io/messa= ge/118971


--00000000000074313c06221b4cef--