Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125580 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 75E611A00BD for ; Tue, 17 Sep 2024 09:56:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726567121; bh=ltguL+oJx8Bs5kUOVhUWnK3B98ovAUY8sxDglPVTalw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jcXDeShYW0nUc1pinsWWHkVpCtu9inyqyAA+72iaPBwZMl4vUn/NJgjRLqylp8Mdc TYUiyD7PiiINYbv7mEdgZJa95cjs35g7VVW8bsnjUJcxi+s3h32/z/a8qU2BXjyRA2 5QCEf0hJ9qFV8pOwkzYNEPbZDt8yymwfkC+dTSxljC2wqoBBFTLedyMteQjfQRdA23 7/OOcQaLwUDMhX4ST65tYgZAaFGUMMSVW3JjoeAif+0qvBd4G5ugNq/tTn6fZMaXcU WBbHIcBUmero/5UU8Rsb4Oyoo3ySwfe6MR2yyjtfnfAJADbok8xyvpExs72PAxNNJY IsMrE7t8YevXw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 26613180054 for ; Tue, 17 Sep 2024 09:58:40 +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_H2,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-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (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 ; Tue, 17 Sep 2024 09:58:36 +0000 (UTC) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a8d4979b843so747532566b.3 for ; Tue, 17 Sep 2024 02:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726566990; x=1727171790; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t0WK4Ylo9AKrPa1xCCyxqqiYizIrLJF/nEocNKscrP8=; b=nHZk3ujn7Klej+9OuElTDhBLJ9FFeoDkgRUQ3doa4gnQFt2yv2rXqQC75/eqvT5bX9 5zHafLxr3e2/d7wXjXm9StFi6/JKUOVmHevud1O7WIL1i9a8v2IqWNhkmJ1/rmZO/mQO USbJxl9BjxFnW4f0L/0fIxu4Vbd7trj74dNCkNZUaxCFl04RPSJIVuLw1kPgZe1itFER zIdDefv8s/w+SLDwHw/Sy8kDSJ0XRles4Br3sbEa3nbmuVd7ZixiEaa2Y4TGPJ4jFfpA t2j8GHZbv3805cn3ib4kTJDkFW0ESnN5WugvgvD9EQr67JotD2LVtZ2n9IWKnrZeoUSV bs9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726566990; x=1727171790; 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=t0WK4Ylo9AKrPa1xCCyxqqiYizIrLJF/nEocNKscrP8=; b=sq0P5xwZVpneUjeEjuIJ8ENDzCf3N5tMo8lopxbRvIMyrbQGgmxDdmZtM72osAs0pz UOt7VyJi8FCIoBuI54WEI16tG3aFLxlMFLdb0z1I9fWV4Hg0F1Q4HV1RvUQIDA5y9Qs/ +toZhtnxZlkRa7NXnOgmt/EY3C3Eqfw0mID1C2tBoyr0g0UtyvP0vXSPYSFelOk47bUZ E6/56ThbWFe7kPCzpA7d20UnBjyZdSIWTGX9K36GnXQT50IW5ED8JeisCD6SnQrTTJ9u enpkgdPLT8571FJiMA/KB1xrSvQKLdrZ0aIQt1anSAUzou6aHZmRuwjjwLlcnh5OTQRv CIvw== X-Gm-Message-State: AOJu0YzoueVuabwn829wDxqefxyVx0qehQuKXD/4FbSZXV1qhrxowby8 KvpplCEx0xkDUx8Ou8msJmB3eJhy2Otvobf2S7/61ki1blY9muTRXq7O/PmZAlb+SIPriPlSJCR gPs3IhcGGmopHRzlH9YWqVbDGQ1QAxpCz X-Google-Smtp-Source: AGHT+IHejdMbEPvzHh1EpqffkbUE2uKwNCrzMBnYhSPY+thr5FKKoAnse+MbrAwgOQvizWpYfgyOSk8VhKUwNW8QOVg= X-Received: by 2002:a17:907:9484:b0:a8d:4b02:334c with SMTP id a640c23a62f3a-a9029679e74mr2025388366b.64.1726566989950; Tue, 17 Sep 2024 02:56:29 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 17 Sep 2024 11:56:03 +0200 Message-ID: Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again) To: Jordan LeDoux Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000001df6c406224db41a" From: kjarli@gmail.com (Lynn) --0000000000001df6c406224db41a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 14, 2024 at 11:51=E2=80=AFPM Jordan LeDoux wrote: > 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 decline= d. > 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 beco= me > 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 congrue= nt > 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 versio= n. > > Operator overloads has come up as a missing feature in several discussion= s > 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 (>, >=3D, =3D=3D, !=3D, <=3D,= <, <=3D>) > has come up more frequently, but particularly in discussion around linear > algebra, arbitrary precision mathematics, and dimensional numbers (such a= s > currency or time), the rest of the operators have also come up. > > Typically, these use cases are themselves very niche, but the capabilitie= s > 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 wa= s > 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-seman= tics.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? Wh= y > 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, ca= n > 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 > > I'm not experienced with other languages and overloading, so consider this reply as me not knowing enough about the subject. Rowan asked an interesting question: "Are we over-riding *operators* or *operations*?" which made me think about behaviors as a 3rd alternative. Instead of individual operator overloading, could classes define how they would act as certain primitives or types that have overloading under the hood? We have `Stringable` with `__toString`, which might not be the best example but does point in a similar direction. I don't know if this is a direction worth exploring but wanted to at least bring it up. ```php interface IntBehavior { public function asInt(): int; } class PositiveInt implements IntBehavior { public readonly int $value; public function __construct(int $value) { $this->value =3D max(0, $value); } public function asInt(): int { return $this->value; } } var_dump(10 + new PositiveInt(5)); // 15 var_dump(new PositiveInt(10) + 15); // 25 var_dump(new PositiveInt(100) + new PositiveInt(100)); // 200 // leaves it to the developer to do: $number =3D new PositiveInt(new PositiveInt(10) + 5); ``` --0000000000001df6c406224db41a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Sep 14, 2024 at 11:51=E2=80= =AFPM Jordan LeDoux <jordan.l= edoux@gmail.com> wrote:

Hello internals,


This discussion will use m= y previous RFC as the starting point for conversation: https://wiki.php.net/rfc/us= er_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 reas= ons, 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 becom= e more clear that these use cases are more common than was suggested previo= usly.

2. Several voters, contributors, and participants have had= more time (years now) to investigate and research some of the related issu= es, which naturally leads to changes in opinion or perspective.

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-weight:400;font-style:normal;font-variant= :normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">= 3. PHP has considered and been receptive toward several RFCs since my origi= nal proposal which update the style of PHP in ways which are congruent with= the KIND of language that has operator overloads.


I mention= ed recently that I would not participate in another operator overload RFC u= nless I felt that the views of internals had become more receptive to the t= opic, and after some discussion with several people off-list, I feel that i= t is at least worth discussing for the next version.


Opera= tor overloads has come up as a missing feature in several discussions on li= st since the previous proposal was declined. This includes:


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-weight:400;font-style:normal;font-variant= :normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">= [RFC] [Discussion] Support object type in BCMath [1]

Native dec= imal 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 requ= est to support comparison operators (>, >=3D, =3D=3D, !=3D, <=3D, = <, <=3D>) has come up more frequently, but particularly in discuss= ion around linear algebra, arbitrary precision mathematics, and dimensional= numbers (such as currency or time), the rest of the operators have also co= me up.


Typically, these use cases are themselves very niche,= but the capabilities operator overloads enable would be much more widely u= sed. From discussion on list, it seems likely that very few libraries would= need to implement operator overloads, but the libraries that do would be w= ell used and thus MANY devs would be consumers of operator overloads.


I want to discuss what changes to the previous proposal people wo= uld be seeking, and why. The most contentious design choice of the previous= proposal was undoubtedly the `operator` keyword and the decision to make o= perator overload implementations distinct from normal magic methods. For so= me 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 i= t was the primary reason they were against the feature.


Ther= e are also several technical and tangentially related items that are being = worked on that would be necessary for operator overloads (and were original= ly included in my implementation of the previous RFC). This includes:


1. Adding a new opcode for LARGER and LARGER_OR_EQUAL so that ope= rand position can be preserved during ALL comparisons.

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

3. Allowin= g values to be equatable without also being orderable (such as with matrice= s, or complex numbers).


These changes could and should be pr= ovided independent of operator overloads. Gina has been working on a separa= te RFC which would cover all three of these issues. You can view the work-i= n-progress on that RFC here: https://gi= thub.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md<= /span>


I hope to start off this discussion productively and work to= wards improving the previous proposal into something that voters are willin= g to pass. To do that, I think these are the things that need to be discuss= ed in this thread:


1. Should the next version of t= his RFC use the `operator` keyword, or should that approach be abandoned fo= r 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 glari= ng design weaknesses in the previous RFC that should be addressed before it= is re-proposed?

4. Do you feel that there is ANY desi= gn, version, or implementation of operator overloads possible that you woul= d 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 a= re most important?


Jordan


External Links:=

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

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

[3]: https://externals.io/message/121387

[4]: h= ttps://externals.io/message/120822

[5]: https://externals.io/message/= 118971



I'm not= experienced with other languages and overloading, so consider this reply a= s me not knowing enough about the subject. Rowan asked an interesting quest= ion: "Are we over-riding *operators* or *operations*?" which made= me think about behaviors as a 3rd alternative. Instead of individual opera= tor overloading, could classes define how they would act as certain primiti= ves or types that have overloading under the hood? We have `Stringable` wit= h `__toString`, which might not be the best example but does point in a sim= ilar direction. I don't know if this is a direction worth exploring but= wanted to at least bring it up.

```php
= interface IntBehavior {
=C2=A0 =C2=A0 public function asInt(): in= t;
}

class PositiveInt implements IntBeh= avior {
=C2=A0 =C2=A0 public readonly int $value;
= =C2=A0 =C2=A0 public function __construct(int $value) {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 $this->value =3D max(0, $value);
=C2=A0 = =C2=A0 }
=C2=A0 =C2=A0 public function asInt(): int {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $this->value;
=C2=A0 =C2=A0= }
}

var_dump(10=C2=A0+ new PositiveInt(= 5)); // 15
var_dump(new PositiveInt(10)=C2=A0+ 15); // 25
var_dump(new PositiveInt(100)=C2=A0+ new P= ositiveInt(100)); // 200

// leaves it to the developer to do:
$number =3D new PositiveInt(new PositiveInt(10)=C2=A0+ 5);
```

=
--0000000000001df6c406224db41a--