Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124086 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 7DE2D1A009C for ; Sun, 30 Jun 2024 11:46:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719748070; bh=Oht/Eg3MexUKBoIOBuoOpWPUyzeV3U9vr34AN3zxlkw=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=Iv8A37Mdc1KHGMTMaa9rum3pLbiAntneCzOw4FG/iHTg/3SPSpOmLCCVdrkFDIAFk POeLciItGdsSMm0wcEjMlkdtzh+fXm8ruhwSmFTboh1YDWLvTiHnc3CGOpjb891Naa 6mrA+kNj576qeau+qP2O5dGJcVIR6yZOvTy+CjQqqJg0iOUD3D5fXVVyXWBE7R+Sqg M2f2gkxEzRZsgfr3sib4HCjt8DQUVoC1/gmxx26pP9uEgvv9Jc52OMRfq7MhWxXmT+ igkiGdO7XXZImrg4/ROuH3ZcHVfvPmpCuZ2ewvJ3nmK5tAX7ZjcRSl8QLGaiZl50yX gAM1YPdrmmBvQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9430F1808AD for ; Sun, 30 Jun 2024 11:47:47 +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 ; Sun, 30 Jun 2024 11:47:44 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id A3CEA1380463; Sun, 30 Jun 2024 07:46:24 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Sun, 30 Jun 2024 07:46:24 -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=1719747984; x= 1719834384; bh=Oht/Eg3MexUKBoIOBuoOpWPUyzeV3U9vr34AN3zxlkw=; b=Y uvjTdc3keeUGxvJiiI4+UXwT3qqq+MLp9qt9btLOuF03yfJNqm65ohgG8bswJoDx SUypHH/xhWZVKB/ZuOGFNRBG5gqgg69KKleYAbDvBG9goX9q35G6UWqd9HBYY8px R558Zfz2Z80R1c19rJveOFqRGEC+z9mTeYc+JQ95YK2Do37hTZKyFTpxIPZ7wRUb +sQWD7FRIUvPlTcOkSXCJFXBIgqVwYvL8M1gC82zD7TGL+yEtUJ0XLZFW8IPY/OT mhREppyzbrCjx5BPOlIcj/hMDBS5R6GGQ/5EZFHOfVVl5J5esPJRQ1KFjtg/IluX CFz2k3YbxOxUJdgQ90CfA== 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=1719747984; x=1719834384; bh=Oht/Eg3MexUKBoIOBuoOpWPUyzeV 3U9vr34AN3zxlkw=; b=TAUIXLD2Vset6yd4x8cTv68MVlFpbyy8Qf1jxRYo0OLn BxoQet8p+J2EWoa0ic4z+0E89FuAEQm8thtYgcg+vEVjaljTzSfaM8NHKovag+/q zlGHv0sXLstUIT2NQfQ4aqN+upPfgv82u+ij8/5a+Tmi0XnCxgOHumQ015Wxa2pf v0noUJ3Z5aKdq1/GgV3aIHxOQGCvrSKJJgZ8FWO4Fad14LyWjI5stinydjxiwyZ3 0OVKuPiPL+fk30ZEGOSliYCySrmaoz4d2LG7L+RL0mt1dve9jSYPrD9+XeLeDVEF 7hq1+PLFkPou3+xORz9mgk/AlS5qv0P2zNOcruKylg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddugdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdftohgs ucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrg htthgvrhhnpedvheekteelveetfeevgeekgfffvdeuhfelveehvdetiefggedtfeejheet gffhueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5D10615A0092; Sun, 30 Jun 2024 07:46:24 -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: <4568C8C6-1E91-4987-973D-3EEC84292252@sakiot.com> References: <257d1b9d-ab54-4538-b044-e89712961598@app.fastmail.com> <4568C8C6-1E91-4987-973D-3EEC84292252@sakiot.com> Date: Sun, 30 Jun 2024 13:46:03 +0200 To: "Saki Takamachi" Cc: "Gina P. Banyard" , internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition Content-Type: multipart/alternative; boundary=d0e37522aaaa46ec84130d56be595ee6 From: rob@bottled.codes ("Rob Landers") --d0e37522aaaa46ec84130d56be595ee6 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Jun 30, 2024, at 13:37, Saki Takamachi wrote: >=20 > Hi, >=20 >> On Sun, Jun 30, 2024, at 13:05, Saki Takamachi wrote: >>>=20 >>> Hi, >>>=20 >>>>> I'm not sure. Does this mean that such "hack" is unavoidable? >>>>>=20 >>>>> And I don't really understand what "pointless hack" means. This wo= uld make sense if operator overloading was already allowed, but it isn't. >>>>=20 >>>> Not unavoidable, but pointless. For example, I attempted to create = a String class that used + for concatenation. This kinda works, but if y= ou pass it to something that takes a string, you get the underlying numb= er and not the string you were trying to store. This is because GMP take= s over casting forcing you to stick to numerical constructs. >>>=20 >>> I don't understand why you only consider the casting case. You can s= imply convert it to a string via a method. As long as don't use any cast= ing at the end, users can implement it however they like. I don't think = this is a pointless hack. >>>=20 >>> Also, allowing "hack" just because they're not useful is not a good = idea. >>=20 >> We could just delete php-src, grab a beer, and watch the sunset. I do= n=E2=80=99t think you=E2=80=99ll ever be able to stop some programmers f= rom hacking things together to solve business problems though. I=E2=80=99= ve =E2=80=9Chacked=E2=80=9D weakmaps in userland to make Hour(1) =3D=3D=3D= (yes, there are three! Equals there) Minute(60). >>=20 >>>=20 >>> Again, if such functionality is provided, it should be exposed as fo= rmal support for operator overloading. >>=20 >> Thank you for your opinion, this RFC doesn=E2=80=99t stop that from h= appening and is completely orthogonal. >>=20 >>>=20 >>>>> This is very confusing me. Why does this need to be a child class = of GMP? >>>>=20 >>>> This is addressed in the current RFC text, if I missed something, p= lease ask! >>>=20 >>> I don't understand why the GMP RFC mentions environments where GMP i= s not used. >>>=20 >>> There are a few other points worth mentioning, but the existence of = polyfills makes this especially confusing. >>>=20 >>> > To be usable, the developer must override the desired operations a= nd make them public >>>=20 >>> Is this referring to a polyfill? Or is this just a necessary step to= override the overload? >>=20 >> I recommend reading up on what a polyfill is, and why they are useful= , if you are confused. But to answer your question, no, it has nothing t= o do with the polyfill, it=E2=80=99s just a necessary step. The polyfill= is just provided for completeness.=20 >>=20 >>>=20 >>> Regards, >>>=20 >>> Saki >>=20 >> =E2=80=94 Rob >=20 > I understand your point, and any further comment from me would probabl= y be of little value to you. This will be my last post on this thread. >=20 > I will definitely vote against this RFC unless the issues I have point= ed out are addressed. No matter how innocuous they may seem, I would rat= her not expose operator overloading in the form of such "hack". >=20 > Regards, >=20 > Saki Thanks, I would love to address your issues but you=E2=80=99ve given me = nothing actionable to work with. Thank you for your time.=20 =E2=80=94 Rob --d0e37522aaaa46ec84130d56be595ee6 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Sun, Jun 30, 2024, at 13:37, Saki Takamachi wrote:
=
Hi,

On Sun, Jun 30, 2024, at 13:05,= Saki Takamachi wrote:

<= div dir=3D"ltr">Hi,

I'm not sure. Does this mean that such "hack" is unavoidabl= e?

And I don't really understand what "poin= tless hack" means. This would make sense if operator overloading was alr= eady allowed, but it isn't.

No= t unavoidable, but pointless. For example, I attempted to create a Strin= g class that used + for concatenation. This kinda works, but if you pass= it to something that takes a string, you get the underlying number and = not the string you were trying to store. This is because GMP takes over = casting forcing you to stick to numerical constructs.

I don't understand why you only consider t= he casting case. You can simply convert it to a string via a method. As = long as don't use any casting at the end, users can implement it however= they like. I don't think this is a pointless hack.

Also, allowing "hack" just because they're not useful is not a = good idea.

We coul= d just delete php-src, grab a beer, and watch the sunset. I don=E2=80=99= t think you=E2=80=99ll ever be able to stop some programmers from hackin= g things together to solve business problems though. I=E2=80=99ve =E2=80= =9Chacked=E2=80=9D weakmaps in userland to make Hour(1) =3D=3D=3D (yes, = there are three! Equals there) Minute(60).


Again, if such functionality is provided, it s= hould be exposed as formal support for operator overloading.

Thank you for your opinion, t= his RFC doesn=E2=80=99t stop that from happening and is completely ortho= gonal.


This is very confusing me. Why does this need to be a chi= ld class of GMP?

This is addre= ssed in the current RFC text, if I missed something, please ask!

I don't understand why the GMP = RFC mentions environments where GMP is not used.

There are a few other points worth mentioning, but the existence o= f polyfills makes this especially confusing.

> T= o be usable, the developer must override the desired operations and make= them public

Is this referring to a polyfill? Or is this just a necessary step to ov= erride the overload?

I recommend reading up on what a polyfill is, and why they are useful= , if you are confused. But to answer your question, no, it has nothing t= o do with the polyfill, it=E2=80=99s just a necessary step. The polyfill= is just provided for completeness. 


Regards,

Saki
=

=E2=80=94 Rob

I unders= tand your point, and any further comment from me would probably be of li= ttle value to you. This will be my last post on this thread.

I will definitely vote against this RFC unless the iss= ues I have pointed out are addressed. No matter how innocuous they may s= eem, I would rather not expose operator overloading in the form of such = "hack".

Regards,

Saki

Thanks, I would love t= o address your issues but you=E2=80=99ve given me nothing actionable to = work with. Thank you for your time. 

=E2=80=94 Rob
--d0e37522aaaa46ec84130d56be595ee6--