Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123996 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 36E871A009C for ; Fri, 28 Jun 2024 19:55:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719604582; bh=HSYbtss6AhSq19qQ0beUp+sQAMfeorPmdvUaAsN9ChM=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=TRtlQchGKBq4NQHIFhYNJFfyq/j4xRVV5Sdulp9e6r6hjDQOlBgttnWHvbshDfmu+ AscfKE46idVLf5MI7MUg19uWO6xAACjE7uqosqR67RjsRIBnJGoFiNdkEw75Eqlj52 H5kiO/GhSTMPPa6PMIea1mCurQ3biqoo4zcALD0IngeuyfsQfsPaNLywqhrZPF/8Kp UyujwJvfEFsnkD0xBDlEKghSaTvcI//aelqNWjsbMj26Ps7HzL3bqqzt/jWD3c1deE BI0BpI7bZmVUAjY605gBLmh25zjj1dEEzXqRstqXhTPfofBeDyBvl609yPJzN0+Lex 9l4JyT9TgO1sg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 90383180003 for ; Fri, 28 Jun 2024 19:56:21 +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.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh6-smtp.messagingengine.com (fhigh6-smtp.messagingengine.com [103.168.172.157]) (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 ; Fri, 28 Jun 2024 19:56:21 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 99323114024E; Fri, 28 Jun 2024 15:55:01 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Fri, 28 Jun 2024 15:55:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1719604501; x= 1719690901; bh=HSYbtss6AhSq19qQ0beUp+sQAMfeorPmdvUaAsN9ChM=; b=Z aW5wXc5veOSS4K/r3sLJXEC00bjOpLQ4+Wqa559ry5gGpTysv/Od+GtOMuN/5nXi gRLFXas66p/5H0HKvS9yHtgfD2yZJG+WAs6FiP9+Cuder4IETFQg2igZ+NoOUf84 gjiOu167oDmGfbL4WzH7fCgV6co93VBwSoLBFwi50UIKMI1UFUL2JZmngYSQf9Qn HEioK+pry4eogavPsH4OjtwZhwEzJBIoOpFRoIq+Oqdu647qh0ap5SOwnGsJJTB2 zADuBUkZxWVPoRKWDce/07NtIhTHcdJzg7pCocgWM1hBralCk5XiAqVm7mdMErxk Ui7ukchtY2wTsIxtP8xoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1719604501; x=1719690901; bh=HSYbtss6AhSq19qQ0beUp+sQAMfe orPmdvUaAsN9ChM=; b=ahxvJRa5uS3XAewudh9Hf0BEtBqQ4JOZw+hIrbXLnqOy 7sxs/Kq6FJI/lIKxDQXBrTEuHCMa5H3+WmU2KWEFLZlsuFGHaCVFissgI60zzc7Q PLg2Q/KRLggpT4Ug9c4Ud5HvQg+00TZEpQJSmd2BAx3KttO7RSEZDm6fJtQK7tDP ATHFp1MPkwqtOSh0wd1XcAPkSFy0kLYcVNxfd1wHC2DZ+Qd+ioV5RWKmBORtYgo+ gpTb9Ja/Y0YfW90Z4liaVx9legzmEA5aZmOFGJo/o+pm+ia60Xx23O2J92m9Wa+j K1UfeNe//zt7FOH5MzS+kMOxZoPtcdbU2vZ/Iegkpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdejgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdftohgs ucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrg htthgvrhhnpeeffeffvedttdejtdevheehieelgeevffeklefhueekgffggeefvdevleek jedvvdenucffohhmrghinhepphhhphdrnhgvthdpvgigthgvrhhnrghlshdrihhonecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosgessgho thhtlhgvugdrtghouggvsh X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3DF9E15A0093; Fri, 28 Jun 2024 15:55:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <8dc5393e-b552-465a-9237-9251e8bf1001@app.fastmail.com> In-Reply-To: References: Date: Fri, 28 Jun 2024 21:54:40 +0200 To: "Jordan LeDoux" Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition Content-Type: multipart/alternative; boundary=03bcd6b3e3a747af8b5b2021992c6c1d From: rob@bottled.codes ("Rob Landers") --03bcd6b3e3a747af8b5b2021992c6c1d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2024, at 20:39, Jordan LeDoux wrote: >=20 >=20 > On Fri, Jun 28, 2024 at 10:47=E2=80=AFAM Rob Landers wrote: >> __ >> Hello internals, >>=20 >> I'd like to introduce a new RFC: https://wiki.php.net/rfc/operator_ov= errides_lite which extends the GMP extension to support a limited set of= operator overriding to developers. It's designed to be limited and rela= tively simple, while still being quite powerful. It would only be availa= ble if you have the GMP extension installed and enabled, but would allow= for creating powerful unit libraries (such as representing money, durat= ion, etc). >>=20 >> I'm very interested in your feedback! >>=20 >> This was initiated from a discussion in another thread: https://exter= nals.io/message/123872 >>=20 >> Thanks for your time, >>=20 >> Rob Landers >=20 > You probably have not actually looked at implementing this yet, so let= me give you some advice: >=20 > 1. You probably are not yet aware that operands get reordered, or thei= r ordering is not guaranteed, when a comparison occurs. This is because = there is no op code (currently) for Greater Than or Greater Than Or Equa= l. Instead the comparison is reordered so that the operands are swapped = and a Less Than or a Less Than Or Equal is performed. This is perfectly = acceptable until you need to determine whether the left or right operand= 's function needs to be called, such as with objects. I actually did know that from implementing something like this for a cli= ent. That is why I chose =E2=80=9Ccomparable=E2=80=9D to let the develop= er decide if two objects are comparable or not. For example, money proba= bly can=E2=80=99t be equal, less than, or more than a plain number, dist= ance, or time. All objects must be comparable for the comparison to succ= eed. I have updated the RFC. > 2. The fact that the signature uses `mixed` for the typing removes a l= ot of the safety features the previous RFC had, and makes a lot of the c= oncerns that stopped that RFC worse. In PHP currently, an object used wi= th any non-comparison operand results in a TypeError. In the previous pr= oposal, this behavior was preserved *even for objects which implement ov= erloads* unless they specifically listed the type as accepted in the ove= rload definition. What this did is ensure that anything OTHER than a Typ= eError guaranteed the developer that they were dealing with an operator = overload that they could go inspect. The mixed type is on purpose until I have an implementation. I haven=E2=80= =99t decided if both will always be a \GMP object or if float|int|string= might get thrown in there too. I want the former, but I=E2=80=99ll have= to see what I can do.=20 I=E2=80=99ll have to look into that exception handling, but I don=E2=80=99= t want to break the current behavior of GMP or make any big changes to s= upport this.=20 > 3. The private/protected distinction is fairly meaningless for the fun= ctions that implement overloads, because the privacy of the function is = ignored completely when it is executed to evaluate an operator. Hmm. I like the idea of protected, because it gives a structure to it th= at is apparent and usable right from the IDE. You just =E2=80=9Cfill in = the blanks=E2=80=9D or stick with the default behavior.=20 > 4. The `static` distinction is also fairly meaningless, as in PHP ther= e is no situation possible where an operator overload can occur WITHOUT = it operating on objects themselves. For this, that is the wrong approach. The actual behavior is on the type= , not the instance. The object instances may not even know their value, = they merely represent the value. > 5. Your voting choices actually constitute something that is not allow= ed for RFCs. A 'yes' vote allows operator overloads for GMP, a 'no' vote= changes GMP to `final`. There is no option here to leave PHP as it curr= ently is, which is what a 'no' vote should mean. Yeah. I was actually wondering about this=E2=80=A6 I believe Gina made i= t kinda clear that it was accidentally non-final. So I was just saving e= veryone an RFC =E2=80=94 maybe I will make it a secondary vote for the c= ase where the RFC is declined. I=E2=80=99ve now updated the RFC.=20 > 6. The `comparable` function you propose doesn't actually have an oper= ator it corresponds to. There is no operator in PHP for "is the left val= ue comparable with the right value". There are operators for comparisons= themselves, which I assume you meant, but a bool is insufficient as a r= eturn type for that. In the engine, there=E2=80=99s just a compare function for internal over= rides. So we just check that everyone agrees that the two objects are co= mparable and then pass it on to =E2=80=9Cbusiness as usual.=E2=80=9D >=20 > There's probably more, but this is a start for you to make some improv= ements and changes. However, I had to warn you before you put in too muc= h effort that I am fairly certain this RFC has very nearly zero chance o= f passing. >=20 > Jordan I have absolutely zero faith this will pass, but I will give it a fair s= hot. It=E2=80=99s the least I can do. =E2=80=94 Rob --03bcd6b3e3a747af8b5b2021992c6c1d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Fri, Jun 28, 2024, at 20:39, Jordan LeDoux wrote:
<= /div>


On Fri, Jun 28, 2024 at 10:47=E2=80= =AFAM Rob Landers <rob@bottled.codes> wrote:

Hello intern= als,

I'd like to introduce a new RFC: = https://wiki.php.net/rfc/operator_ove= rrides_lite which extends the GMP extension to support a limite= d set of operator overriding to developers. It's designed to be limited = and relatively simple, while still being quite powerful. It would only b= e available if you have the GMP extension installed and enabled, but wou= ld allow for creating powerful unit libraries (such as representing mone= y, duration, etc).

I'm very interested in y= our feedback!

This was initiated from a dis= cussion in another thread: https://externals.= io/message/123872

Thanks for your time,=

Rob Landers

You probably have not actually looked at impleme= nting this yet, so let me give you some advice:

=
1. You probably are not yet aware that operands get reordered, or t= heir ordering is not guaranteed, when a comparison occurs. This is becau= se there is no op code (currently) for Greater Than or Greater Than Or E= qual. Instead the comparison is reordered so that the operands are swapp= ed and a Less Than or a Less Than Or Equal is performed. This is perfect= ly acceptable until you need to determine whether the left or right oper= and's function needs to be called, such as with objects.
=

I actually did know that from imp= lementing something like this for a client. That is why I chose =E2=80=9C= comparable=E2=80=9D to let the developer decide if two objects are compa= rable or not. For example, money probably can=E2=80=99t be equal, less t= han, or more than a plain number, distance, or time. All objects must be= comparable for the comparison to succeed. I have updated the RFC.
=

2. The fact that the signature = uses `mixed` for the typing removes a lot of the safety features the pre= vious RFC had, and makes a lot of the concerns that stopped that RFC wor= se. In PHP currently, an object used with any non-comparison operand res= ults in a TypeError. In the previous proposal, this behavior was preserv= ed *even for objects which implement overloads* unless they specifically= listed the type as accepted in the overload definition. What this did i= s ensure that anything OTHER than a TypeError guaranteed the developer t= hat they were dealing with an operator overload that they could go inspe= ct.

The mixed type= is on purpose until I have an implementation. I haven=E2=80=99t decided= if both will always be a \GMP object or if float|int|string might get t= hrown in there too. I want the former, but I=E2=80=99ll have to see what= I can do. 

I=E2=80=99ll have to look = into that exception handling, but I don=E2=80=99t want to break the curr= ent behavior of GMP or make any big changes to support this. 
=

3. The private/protected distin= ction is fairly meaningless for the functions that implement overloads, = because the privacy of the function is ignored completely when it is exe= cuted to evaluate an operator.
Hmm. I like the idea of protected, because it gives a struc= ture to it that is apparent and usable right from the IDE. You just =E2=80= =9Cfill in the blanks=E2=80=9D or stick with the default behavior. =

4. The `static` distinct= ion is also fairly meaningless, as in PHP there is no situation possible= where an operator overload can occur WITHOUT it operating on objects th= emselves.

For this= , that is the wrong approach. The actual behavior is on the type, not th= e instance. The object instances may not even know their value, they mer= ely represent the value.

<= div>5. Your voting choices actually constitute something that is not all= owed for RFCs. A 'yes' vote allows operator overloads for GMP, a 'no' vo= te changes GMP to `final`. There is no option here to leave PHP as it cu= rrently is, which is what a 'no' vote should mean.
=

Yeah. I was actually wondering about th= is=E2=80=A6 I believe Gina made it kinda clear that it was accidentally = non-final. So I was just saving everyone an RFC =E2=80=94 maybe I will m= ake it a secondary vote for the case where the RFC is declined. I=E2=80=99= ve now updated the RFC. 

=
6. The `comparable` function you propose doesn't actually have an o= perator it corresponds to. There is no operator in PHP for "is the left = value comparable with the right value". There are operators for comparis= ons themselves, which I assume you meant, but a bool is insufficient as = a return type for that.

In the engine, there=E2=80=99s just a compare function for interna= l overrides. So we just check that everyone agrees that the two objects = are comparable and then pass it on to =E2=80=9Cbusiness as usual.=E2=80=9D=


There's p= robably more, but this is a start for you to make some improvements and = changes. However, I had to warn you before you put in too much effort th= at I am fairly certain this RFC has very nearly zero chance of passing.<= br>

Jordan

I have absolutely zero faith this will pass, but I wil= l give it a fair shot. It=E2=80=99s the least I can do.

=E2=80=94 Rob
--03bcd6b3e3a747af8b5b2021992c6c1d--