Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123983 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 1191F1A009C for ; Fri, 28 Jun 2024 07:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719558397; bh=jzkPxPeLH5GSwt3Gt1CxzwPBJ8TxjF314mXR6YSLeNU=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=AJka+XLyjScQPWRQjoiEDaWPn7UAxSpDYCqyXEGx3tsDpTgmrDDqfYDzqiU3N2Ld6 5KGTTEsAXc5PBw+rLOvRiQpf2v00Hm/1fojV5XOILzvUm9EH6dUIywXWez4AdADWcM USaOlGz6+n7ilZ+nIuONJflU64bD+cP2geyf+x50czD2DaN5+lQ1AB9eCnj9mVzZ1y BVB4u+g66j56wKCCCqdUp2Wcrk9qFKkcejq1c95xPCHQJTGdDUXgWSL+dJsG9DwlUb MbefeDmu+TqnPcO70obt7/i4q3HwjkqD9AaIo62Rw/fvWxncJBzPu7+evoSSNehjMB U3XGD4QdCXBqQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6FCA9180696 for ; Fri, 28 Jun 2024 07:06:36 +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 fout2-smtp.messagingengine.com (fout2-smtp.messagingengine.com [103.168.172.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 28 Jun 2024 07:06:35 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 193C31380677; Fri, 28 Jun 2024 03:05:17 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Fri, 28 Jun 2024 03:05:17 -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=1719558317; x= 1719644717; bh=jzkPxPeLH5GSwt3Gt1CxzwPBJ8TxjF314mXR6YSLeNU=; b=t lDYFYn1W1tWVI9bC52Y1GOBAJanA87KT9vrxhjbAw2zRIfr9hXeBqjjJDh7oTQpx XpK8EY7OS58qdKpVZETLJbdnMAHTuadVXP+qWz3AUw7ykLtmOmMn4tXz1lsqcyKD bLVdbjLYWpMrpF/ljIKi4yr73dPBAupg87uncJow5QZl1QCIN66CSi732NUcdiVx o/XKukFlzxUF3KmI3H4UtRecLpL8ztFBI7vUAZ8Y2hvgyaGfvXuFUgReFIaV96Sx 2bGQ0zeOmA3yCcIkcxPaa6I3S0jTIbFloWMRAyqWH/gsT32zn5wVaxL5TjamXmvd Ue9z/8owVCYo0zNxyiS9A== 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=1719558317; x=1719644717; bh=jzkPxPeLH5GSwt3Gt1CxzwPBJ8Tx jF314mXR6YSLeNU=; b=gDCAtjwUWlDUQpHVM8i/QurLt8+ao601aSvsNrtukOPQ K+CFBiLZJxwdpG/NcGMdEst/A4XNN+jxazGBKXXUM2Smw9RSmjJsaKcn9dyXTuPh dfEZ166iEf2UQzEPMeaanMV/dTQLVbM/n5fQZrX80KvLA/F8z3xHxJde5GFFIp5z 6uDSx5S3EJhW/KKJRQie51Gz8BuEMtYrr/6q2E4zEgOzCfIMoemE2wm+BGa7Hvf3 ABbKU1r2lc/OOuNzoVKiIRiDhbF7l8fNaWwh60TQqxRpW03wN0shjdoWQPUy0dAg 4Pn5PvbIOuklc6+NuPQ5mZTbm5MCp1FKSi0oM3pDCQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdehgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedftfho sgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrf grthhtvghrnhepvdehkeetleevteefveegkefgffdvuefhleevhedvteeigfegtdefjeeh tefghfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprhhosgessghothhtlhgvugdrtghouggvsh X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5DCC715A0092; Fri, 28 Jun 2024 03:05:16 -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: In-Reply-To: <38C21842-1740-48A2-B2F1-0FFA57D542F4@sakiot.com> References: <38C21842-1740-48A2-B2F1-0FFA57D542F4@sakiot.com> Date: Fri, 28 Jun 2024 09:04:56 +0200 To: "Saki Takamachi" Cc: "Gina P. Banyard" , internals@lists.php.net Subject: Re: [PHP-DEV] Overriding GMP objects Content-Type: multipart/alternative; boundary=082a382f9f31473885deafbf96f4d71f From: rob@bottled.codes ("Rob Landers") --082a382f9f31473885deafbf96f4d71f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2024, at 02:43, Saki Takamachi wrote: > Hi Rob, >=20 > >> On Thu, Jun 27, 2024, at 06:07, Saki Takamachi wrote: > >>=20 > >> I agree with Gina. Being able to change the class of a computed res= ult of an inherited child class causes several problems. > >>=20 > >> The points raised in the `BCMath\Number` discussion can be summariz= ed as follows. > >>=20 > >> - If it is possible to perform calculations on parent Class and chi= ld Class, what should the resulting class be? > >=20 > > Ask the class what it wants to be? > >=20 > >> - Multiplying the distance class and the speed class should give yo= u the time class. > >=20 > > That would depend on the library=E2=80=99s implementation.=20 > >=20 > >> - Similarly, multiplying two distance classes together should yield= an area class. > >=20 > > See above.=20 > >=20 > >> - If only child classes have a property that should be specified in= the constructor, how do you determine the value of this property in the= result class? Perhaps it is possible to determine the value of the prop= erty, but in that case the commutativity of the computation should be lo= st. > >=20 > > This can be handled via the child class in static methods, per the l= ibrary specifications. > >=20 > >>=20 > >> These problems cannot be solved without significant complexity. And= there is a possibility that it cannot be resolved in the first place. > >=20 > > I very much disagree; there is very little complications in the exte= nsion. It=E2=80=99s actually quite simple: > >=20 > > If one value is scalar and the other an instance of GMP, for binary = ops, ask the GMP class to perform the operation. (This is a one-linish c= hange) > >=20 > > If both are GMP instances, in a binary op, ask the left-most one to = perform the op. The default GMP implementation will delegate to the righ= t-side if the right side isn=E2=80=99t a base-GMP instance, otherwise, b= usiness as usual. > >=20 > > And that=E2=80=99s pretty much it, other than defining the base-type= ops. From there, you can implement any units library you want, with wha= tever behavior makes sense =E2=80=94 so long as the base representation = is a number. > >=20 > > If I remember the original operator overloading RFC, this is exactly= what was asked for by the people who voted no. In theory, it should pas= s if brought as an RFC.=20 > >=20 > > =E2=80=94 Rob >=20 > I see. >=20 > All of what I wrote are problems that arise when php doesn't provide a= way to control them in userland. >=20 > Your proposal implicitly allows operator overloading in userland. I wouldn=E2=80=99t go that far. First of all, it would only apply to num= erical constructs and operations; there=E2=80=99s no way to override con= catenation (so you can=E2=80=99t make concatenation act like a dot-produ= ct); I=E2=80=99m not considering things like less-than/greater-than or e= ven equals. I=E2=80=99m only considering mathematical operators, like +,= -, /, %, etc. And lastly, there=E2=80=99s no special syntax like you wo= uld expect from proper operator overloads. If anything, I would consider this operator overloading, lite edition. >=20 > So your proposal essentially amounts to allowing operator overloading = only for GMP classes. Yes, this would basically amount to being able to have some typed contro= l over types of numbers (aka, units) or in simpler words: limited overlo= ading is available for anything that can be backed by a single numerical= value.=20 >=20 > If I understand correctly, this discussion is not centered on GMP, but= on the topic of limited exposure of operator overloading functionality. It=E2=80=99s centered on GMP because the resource converted to object wa= s left non-final, thus providing a way to provide a =E2=80=9Ctyped numbe= r=E2=80=9D to the engine. This actually presents a unique opportunity to= implement a limited form of operator overloading in a way that is stric= tly opt-in (must have the GMP extension), useful, and what the detractor= s wanted on the last RFC (no special syntax, limited scope, some don=E2=80= =99t want it at all =E2=80=94 this is opt-in). To me, this seems like ex= actly what was asked for. > I believe this is something that requires some very careful discussion. I agree and also disagree. We have an already well-thought out and resea= rched, yet declined, RFC on the matter that can be used for reference. T= his means there is probably a lot we don=E2=80=99t need to think too har= d on. Then there is the fact that this is in an extension, and not a ver= y common one. Who knows, maybe having a limited form of operator overloa= ding might convince people that proper operator overloading would be ben= eficial.=20 I=E2=80=99ll go ahead and write up an RFC and then it can be discussed p= roperly.=20 And fwiw, yes it =E2=80=9Cfeels hacky af=E2=80=9D but interestingly, als= o makes a lot of sense in the environment we find ourselves in.=20 =E2=80=94 Rob --082a382f9f31473885deafbf96f4d71f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Fri, Jun 28, 2024, at 02:43, Saki Takamachi wrote:
=
Hi Rob,

>> On Thu, Jun 27, 2024, at 06:07, Saki Tak= amachi wrote:
>> 
>> I agre= e with Gina. Being able to change the class of a computed result of an i= nherited child class causes several problems.
>>&nbs= p;
>> The points raised in the `BCMath\Number` discu= ssion can be summarized as follows.
>> 
>> - If it is possible to perform calculations on parent Cl= ass and child Class, what should the resulting class be?
&= gt; 
> Ask the class what it wants to be?
> 
>> - Multiplying the distance class= and the speed class should give you the time class.
>&= nbsp;
> That would depend on the library=E2=80=99s impl= ementation. 
> 
>> - Simi= larly, multiplying two distance classes together should yield an area cl= ass.
> 
> See above. 
> 
>> - If only child classes have a= property that should be specified in the constructor, how do you determ= ine the value of this property in the result class? Perhaps it is possib= le to determine the value of the property, but in that case the commutat= ivity of the computation should be lost.
> 
> This can be handled via the child class in static methods, = per the library specifications.
> 
&= gt;> 
>> These problems cannot be solved wit= hout significant complexity. And there is a possibility that it cannot b= e resolved in the first place.
> 
&g= t; I very much disagree; there is very little complications in the exten= sion. It=E2=80=99s actually quite simple:
> 
> If one value is scalar and the other an instance of GMP, f= or binary ops, ask the GMP class to perform the operation. (This is a on= e-linish change)
> 
> If both are= GMP instances, in a binary op, ask the left-most one to perform the op.= The default GMP implementation will delegate to the right-side if the r= ight side isn=E2=80=99t a base-GMP instance, otherwise, business as usua= l.
> 
> And that=E2=80=99s pretty= much it, other than defining the base-type ops. From there, you can imp= lement any units library you want, with whatever behavior makes sense =E2= =80=94 so long as the base representation is a number.
>= ; 
> If I remember the original operator overloadi= ng RFC, this is exactly what was asked for by the people who voted no. I= n theory, it should pass if brought as an RFC. 
>&= nbsp;
> =E2=80=94 Rob

I se= e.

All of what I wrote are problems that ar= ise when php doesn't provide a way to control them in userland.

Your proposal implicitly allows operator overloadin= g in userland.

I wouldn=E2=80=99= t go that far. First of all, it would only apply to numerical constructs= and operations; there=E2=80=99s no way to override concatenation (so yo= u can=E2=80=99t make concatenation act like a dot-product); I=E2=80=99m = not considering things like less-than/greater-than or even equals. I=E2=80= =99m only considering mathematical operators, like +, -, /, %, etc. And = lastly, there=E2=80=99s no special syntax like you would expect from pro= per operator overloads.

If anything, I woul= d consider this operator overloading, lite edition.


S= o your proposal essentially amounts to allowing operator overloading onl= y for GMP classes.

Yes, this w= ould basically amount to being able to have some typed control over type= s of numbers (aka, units) or in simpler words: limited overloading is av= ailable for anything that can be backed by a single numerical value.&nbs= p;


If I understand correctly, this discussion is not cent= ered on GMP, but on the topic of limited exposure of operator overloadin= g functionality.

It=E2=80=99s = centered on GMP because the resource converted to object was left non-fi= nal, thus providing a way to provide a =E2=80=9Ctyped number=E2=80=9D to= the engine. This actually presents a unique opportunity to implement a = limited form of operator overloading in a way that is strictly opt-in (m= ust have the GMP extension), useful, and what the detractors wanted on t= he last RFC (no special syntax, limited scope, some don=E2=80=99t want i= t at all =E2=80=94 this is opt-in). To me, this seems like exactly what = was asked for.

I believe this is something that requires some very c= areful discussion.

I agree and= also disagree. We have an already well-thought out and researched, yet = declined, RFC on the matter that can be used for reference. This means t= here is probably a lot we don=E2=80=99t need to think too hard on. Then = there is the fact that this is in an extension, and not a very common on= e. Who knows, maybe having a limited form of operator overloading might = convince people that proper operator overloading would be beneficial.&nb= sp;

I=E2=80=99ll go ahead and write up an R= FC and then it can be discussed properly. 

=
And fwiw, yes it =E2=80=9Cfeels hacky af=E2=80=9D but interestingly= , also makes a lot of sense in the environment we find ourselves in.&nbs= p;

=E2=80=94 Rob
<= /body> --082a382f9f31473885deafbf96f4d71f--