Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124084 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 A81061A009C for ; Sun, 30 Jun 2024 11:37:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719747529; bh=RfFAs+kcqpDZ9NfB6iNoys2O28E7p7eFQB+86rWhDIM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=oSamGwM2f8OUrD/H+fHLayW+3XPLaz8iU/J3ieNn98L9zx0tq6L1SH9Vs1TCPEzNd VkQfq08IzXfJVMVCg5fbh+sXPdPW3MwF8nmIR27st83B8UZu7GDD9GVZXENv7DuHEl ELsAo7/YlmSHVDn6V/p4VvM0mjZ54kx1alRU0TX6BmRJQsft2uRTFjGdfumZS2gYZN N/cmloICDV1k4YZCtdsGQ1HU1M4qaQtchRlj2Qdht8dBCS7TUgxTnlbfs+JdB78mN3 rXgIQoFXST3Ebfab0ZfiYABaYp7tShJNYrA4g/kQQtoqOI2D/6w5kNZV3/vkg4ioe6 fq6cL9H7WLD3Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A787418083E for ; Sun, 30 Jun 2024 11:38:48 +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,HTML_MESSAGE, MIME_QP_LONG_LINE,SPF_HELO_NONE,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 mail.sakiot.com (mail.sakiot.com [160.16.227.216]) (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 ; Sun, 30 Jun 2024 11:38:47 +0000 (UTC) Received: from smtpclient.apple (229.152.159.133.rev.vmobile.jp [133.159.152.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.sakiot.com (Postfix) with ESMTPSA id 8849F401D3; Sun, 30 Jun 2024 20:37:23 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sakiot.com; s=default; t=1719747443; bh=RfFAs+kcqpDZ9NfB6iNoys2O28E7p7eFQB+86rWhDIM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=iDglGgTE96wFPK5NhRxBMKa7wmmmM/STx2WjS2yHM/AvFnAB48+TAUwoSkI9E0r4V YNzNH18I+3GEAYMidRZRvb8hh9VLTcFOHhAeoU8Bxbvh30lUOcsclGtqTdBtHkoy7t MH5NT5m5x92ata4XHDSTIF2TVitD8Si0A1mXjuEw= Content-Type: multipart/alternative; boundary=Apple-Mail-7E5BF3E4-625E-4B74-B707-D94E6C8D44D9 Content-Transfer-Encoding: 7bit Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (1.0) Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition Date: Sun, 30 Jun 2024 20:37:11 +0900 Message-ID: <4568C8C6-1E91-4987-973D-3EEC84292252@sakiot.com> References: <257d1b9d-ab54-4538-b044-e89712961598@app.fastmail.com> Cc: "Gina P. Banyard" , internals@lists.php.net In-Reply-To: <257d1b9d-ab54-4538-b044-e89712961598@app.fastmail.com> To: Rob Landers X-Mailer: iPhone Mail (21F90) From: saki@sakiot.com (Saki Takamachi) --Apple-Mail-7E5BF3E4-625E-4B74-B707-D94E6C8D44D9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, >> 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 would m= ake sense if operator overloading was already allowed, but it isn't. >>>=20 >>> Not unavoidable, but pointless. For example, I attempted to create a Str= ing class that used + for concatenation. This kinda works, but if you pass i= t to something that takes a string, you get the underlying number and not th= e string you were trying to store. This is because GMP takes over casting fo= rcing you to stick to numerical constructs. >>=20 >> I don't understand why you only consider the casting case. You can simply= convert it to a string via a method. As long as don't use any casting at th= e end, users can implement it however they like. I don't think this is a poi= ntless 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 don=E2=80= =99t think you=E2=80=99ll ever be able to stop some programmers from hacking= things together to solve business problems though. I=E2=80=99ve =E2=80=9Cha= cked=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 formal s= upport for operator overloading. >=20 > Thank you for your opinion, this RFC doesn=E2=80=99t stop that from happen= ing and is completely orthogonal. >=20 >>=20 >>>> This is very confusing me. Why does this need to be a child class of GM= P? >>>=20 >>> This is addressed in the current RFC text, if I missed something, please= ask! >>=20 >> I don't understand why the GMP RFC mentions environments where GMP is not= used. >>=20 >> There are a few other points worth mentioning, but the existence of polyf= ills makes this especially confusing. >>=20 >> > To be usable, the developer must override the desired operations and ma= ke them public >>=20 >> Is this referring to a polyfill? Or is this just a necessary step to over= ride the overload? >=20 > I recommend reading up on what a polyfill is, and why they are useful, if y= ou are confused. But to answer your question, no, it has nothing to do with t= he polyfill, it=E2=80=99s just a necessary step. The polyfill is just provid= ed for completeness.=20 >=20 >>=20 >> Regards, >>=20 >> Saki >=20 > =E2=80=94 Rob I understand your point, and any further comment from me would probably be o= f little value to you. This will be my last post on this thread. I will definitely vote against this RFC unless the issues I have pointed out= are addressed. No matter how innocuous they may seem, I would rather not ex= pose operator overloading in the form of such "hack". Regards, Saki= --Apple-Mail-7E5BF3E4-625E-4B74-B707-D94E6C8D44D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,=

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

Hi,

<= /div>
I'm not sure. Does this mean that such "hack" is u= navoidable?

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

Not un= avoidable, but pointless. For example, I attempted to create a String class t= hat used + for concatenation. This kinda works, but if you pass it to someth= ing that takes a string, you get the underlying number and not the string yo= u were trying to store. This is because GMP takes over casting forcing you t= o stick to numerical constructs.

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

Also, allowing "hack" just becaus= e they're not useful is not a good idea.
<= div>
We could just delete php-src, grab a beer, and watch the s= unset. I don=E2=80=99t think you=E2=80=99ll ever be able to stop some progra= mmers from hacking 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 should b= e exposed as formal support for operator overloading.
<= /blockquote>

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

This is very confusing me. W= hy does this need to be a child class of GMP?
This is addressed in the current RFC text, if I missed something= , please ask!

I don't unders= tand why the GMP RFC mentions environments where GMP is not used.
<= div>
There are a few other points worth mentioning, but the ex= istence of polyfills makes this especially confusing.

> To be usab= le, the developer must override the desired operations and make them public<= /span>

Is this referring to a polyfill? O= r is this just a necessary step to override the overload?

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

Regards,

Saki

=E2=80= =94 Rob

I understand your point, and an= y further comment from me would probably be of little value to you. This wil= l be my last post on this thread.

I will definitely= vote against this RFC unless the issues I have pointed out are addressed. N= o matter how innocuous they may seem, I would rather not expose operator ove= rloading in the form of such "hack".

Regards,
=

Saki
= --Apple-Mail-7E5BF3E4-625E-4B74-B707-D94E6C8D44D9--