Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124034
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <90ab0ec1-33ad-4342-ad4b-6448ee89bfa7@app.fastmail.com>
In-Reply-To: <89C9AC15-1456-46AE-9183-DFDA7D0D381D@sakiot.com>
References: <90dd3eb6-c7be-4951-a6b6-fd3785ed92e5@app.fastmail.com>
 <89C9AC15-1456-46AE-9183-DFDA7D0D381D@sakiot.com>
Date: Sat, 29 Jun 2024 15:34:08 +0200
To: "Saki Takamachi" <saki@sakiot.com>
Cc: "Jordan LeDoux" <jordan.ledoux@gmail.com>, internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
Content-Type: multipart/alternative;
 boundary=d00c28e55b25471480ca722c24b497ed
From: rob@bottled.codes ("Rob Landers")

--d00c28e55b25471480ca722c24b497ed
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024, at 14:28, Saki Takamachi wrote:
>=20
> Hi,
>=20
>> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
>>>>> 4. The `static` distinction is also fairly meaningless, as in PHP =
there is no situation possible where an operator overload can occur WITH=
OUT it operating on objects themselves.
>>>>=20
>>>> 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 va=
lue, they merely represent the value.
>>>=20
>>> A GMP object instance that does not know its value? What are you eve=
n talking about? Can you show me some code explaining what you mean? I h=
ad literally months of this argument for the operator overloads RFC, and=
 studied the overload implementations in six other languages as part of =
writing that RFC, I feel like I understand this topic fairly well. But I=
 do not understand what you are saying here.
>>=20
>> A few minutes ago, I sent an email where I accidentally made the code=
 non-static, and I think I see the merit in what you are saying. It felt=
 so natural to use $this that I didn't even realize I was doing it wrong.
>>=20
>> So, looking at your RFC and mine, I think this can be improved.
>>=20
>> What would you suggest it look like and then we can work backwards fr=
om there?
>=20
> Here are my thoughts on your code.
>=20
> In theory, inheriting from this "improved GMP class" would allow overl=
oading of computational operators.
>=20
> In effect, this acts like a "calcable interface", with the constructor=
 passing in meaningless values to the parent constructor and the add met=
hod allowing the user to freely modify the return value.
>=20
> This means that virtually any userland class can use the operator over=
loading feature via a "hack".

That is a very valid point, and I feel like it is something I definitely=
 would have thought about since I love abusing features to do things the=
y shouldn't. My hope was that by removing the ability to directly compar=
e, it would reduce the usefulness of "hacking it" into generic overloadi=
ng since you have to return a GMP instance ... but then, I guess, that G=
MP instance technically doesn't have to represent a number (though the r=
est of the engine will very much treat it as a number).

I will think on this some more...

For example, while eating lunch, I was considering whether this even nee=
ds to have anything to do with the GMP instance. I was only focusing on =
the GMP class because right now, it is non-final. Then I started thinkin=
g about Jordan's original proposal and how it could be simplified ... th=
ere's certainly things to think about.

> This approach is completely wrong.=20

Ouch, I would hope it would have something useful to it. :)

>=20
> Rather than proposing this as is, it would be more constructive to pro=
pose support for operator overloading.

That's been tried before, and this was an attempt at the far other extre=
me, "barely operator overloading". So, there is surely something in the =
middle. Hopefully.

=E2=80=94 Rob
--d00c28e55b25471480ca722c24b497ed
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Jun 29,=
 2024, at 14:28, Saki Takamachi wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div dir=3D"ltr"><br></div><div dir=3D"ltr">Hi,<b=
r></div><div dir=3D"ltr"><div><br></div><blockquote type=3D"cite">On Sat=
, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:<br></blockquote></div><bl=
ockquote type=3D"cite"><div dir=3D"ltr"><blockquote type=3D"cite" id=3D"=
qt-qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-qt-gmail_quote"><blo=
ckquote class=3D"qt-qt-gmail_quote" style=3D"margin-top:0px;margin-right=
:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><=
div class=3D"qt-qt-msg3306475242208035808"><div><blockquote type=3D"cite=
" id=3D"qt-qt-m_3306475242208035808qt"><div dir=3D"ltr"><div><div>4. The=
 `static` distinction is also fairly meaningless, as in PHP there is no =
situation possible where an operator overload can occur WITHOUT it opera=
ting on objects themselves.<br></div></div></div></blockquote><div><br><=
/div><div>For this, that is the wrong approach. The actual behavior is o=
n the type, not the instance. The object instances may not even know the=
ir value, they merely represent the value.<br></div></div></div></blockq=
uote><div><br></div><div>A GMP object instance that does not know its va=
lue? What are you even talking about? Can you show me some code explaini=
ng what you mean? I had literally months of this argument for the operat=
or overloads RFC, and studied the overload implementations in six other =
languages as part of writing that RFC, I feel like I understand this top=
ic fairly well. But I do not understand what you are saying here.<br></d=
iv></div></div></blockquote><div><br></div><div>A few minutes ago, I sen=
t an email where I accidentally made the code non-static, and I think I =
see the merit in what you are saying. It felt so natural to use $this th=
at I didn't even realize I was doing it wrong.<br></div><div><br></div><=
div>So, looking at your RFC and mine, I think this can be improved.<br><=
/div><div><br></div><div>What would you suggest it look like and then we=
 can work backwards from there?<br></div></div></blockquote><div><br></d=
iv><div>Here are my thoughts on your code.<br></div><div><br></div><div>=
In theory, inheriting from this "improved GMP class" would allow overloa=
ding of computational operators.<br></div><div><br></div><div>In effect,=
 this acts like a "calcable interface", with the constructor passing in =
meaningless values to the parent constructor and the add method allowing=
 the user to freely modify the return value.<br></div><div><br></div><di=
v>This means that virtually any userland class can use the operator over=
loading feature via a "hack".<br></div></blockquote><div><br></div><div>=
That is a very valid point, and I feel like it is something I definitely=
 would have thought about since I love abusing features to do things the=
y shouldn't. My hope was that by removing the ability to directly compar=
e, it would reduce the usefulness of "hacking it" into generic overloadi=
ng since you have to return a GMP instance ... but then, I guess, that G=
MP instance technically doesn't have to represent a number (though the r=
est of the engine will very much treat it as a number).<br></div><div><b=
r></div><div>I will think on this some more...<br></div><div><br></div><=
div>For example, while eating lunch, I was considering whether this even=
 needs to have anything to do with the GMP instance. I was only focusing=
 on the GMP class because right now, it is non-final. Then I started thi=
nking about Jordan's original proposal and how it could be simplified ..=
. there's certainly things to think about.</div><div><br></div><blockquo=
te type=3D"cite" id=3D"qt" style=3D""><div>This approach is completely w=
rong. <br></div></blockquote><div><br></div><div>Ouch, I would hope it w=
ould have something useful to it. :)</div><div><br></div><blockquote typ=
e=3D"cite" id=3D"qt" style=3D""><div><br></div><div>Rather than proposin=
g this as is, it would be more constructive to propose support for opera=
tor overloading.<br></div></blockquote><div><br></div><div>That's been t=
ried before, and this was an attempt at the far other extreme, "barely o=
perator overloading". So, there is surely something in the middle. Hopef=
ully.<br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br>=
</div></body></html>
--d00c28e55b25471480ca722c24b497ed--