Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125610 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 E90011A00BD for ; Wed, 18 Sep 2024 00:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726619965; bh=Q35QnScj5ye5+uUvFqDpBSRQt7bTVJxQTnXUhoLzj1U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Hk8nZa2vE9n9Tg45d+Lj9YH7g+ilObkYP5zAWEmbVKktjC16vu/LYy+SkbUpjFSai httDccf7oe2qEJqA8D4T7oFRTBfkLy8gaeZGYOoymKOOzmSHnlq5ZlfsYZfQzCC0IQ BvYDuu1LCrPsNCRrgc+apoHP4drmrnYoIFYJndoZMChxaMTZ5AMQdy/w6lHeIKCQ0E hz41V+qSKzFW522AstbdxYI7evImafv1XNmM7OTsK4/Wl7eG+V2epM+xXNJb1Kg5z4 D5F3pBUckk3yV6ONxyh0xzWW9eiolJcowIyWgr5KIRSro1hltMvF7+ACF+Spak5xFQ YV8dSKyxuaDfg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A5CC318005C for ; Wed, 18 Sep 2024 00:39:24 +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,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 ; Wed, 18 Sep 2024 00:39:24 +0000 (UTC) Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-710dead5d2aso3394051a34.0 for ; Tue, 17 Sep 2024 17:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726619838; x=1727224638; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dwJgrwmVHo1xBMFp0ZRLJQXuvbPMV83DQxODnHh+uvU=; b=WILZIjXmmKHsKaI1+XK4s2gfYftmKmkQxj6jeJeMfielqU1n5lJHToiDsptsW5Gstu lmO7gF+Urhy3HewEtfeezZ2cskoBs6NReskstLkAMFh7vonwjnyV2n3RN+Lu5/vc1Cbj VUQs6qr7b2b6S3vw3Clcq5slKXLs88298BM3Bcjr+0vd+5I/a4N+Zv0twV7bJg3ErMA5 YZ9ssuHFVczuDTZa6xqv7EnxdUMVRC/S5KIN0UYxXJVOJMMWpexJmmrKqRVq40WKQiN2 +DUJFoXzvNAjbxWWtwVEVYNKEMCCxRVSNbcQJL7noLchL7cPb5Z39b4sAdussw4Y8omv o5EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726619838; x=1727224638; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dwJgrwmVHo1xBMFp0ZRLJQXuvbPMV83DQxODnHh+uvU=; b=SfFY2LBmk1KoS2PkIkUW1fkJ9cjygZZJs3jd+kFDbpuFL8snAbZfuI7K/MUjQbSIFi 0Uxk2ha1YX804eDhbfFHPabcs+hQLPZTN8tNPzAxKW6HQ8SGj/Y1G6h1apJ7/Vho3dm4 hm1TK0TwRfwOE/+d6Z660dsdAGLsXPkPGmQVgKSABjyH7iGB/0YrUXdRLM4wcOezLuld zHLob2RqJowjMO6RYFx4kvreoY9f3iLHBqDBm2E7NrdUdHhpwjnnrezI+pPTSIonfGz1 dA7z32WBgd3nqN1n+HIOWGo087n/kdlQ6ApzAdsKUlv6QkJlc2SBN0o0nLsLGOtx38fb qSvA== X-Gm-Message-State: AOJu0YzrPdv1ptCXhkgjVsWQnakI3lbecWKRDd3jmncwrblzPV1+NxFQ WP4rgcIq5GGDZ2DowKXGUpbv9X4OSNoSgSCKl4ehLCqGd/HJv39BmaI30R6UupKUtumSS9FHM7s TxDm7/bmdsfQNpdjNfIyf9e7KH78/KNja X-Google-Smtp-Source: AGHT+IE+BW0fWjPMkKfhyuGofLYut5jQtsbMX4D/OdMO55bpjhiwogF235x9qGJv7PcSf8U87uhut5/sPdduyJpZvts= X-Received: by 2002:a05:6830:6319:b0:70a:94b4:6e67 with SMTP id 46e09a7af769-711094b4bcemr12211792a34.23.1726619838003; Tue, 17 Sep 2024 17:37:18 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net> In-Reply-To: Date: Tue, 17 Sep 2024 18:37:07 -0600 Message-ID: Subject: Re: [PHP-DEV] Zephir, and other tangents To: Mike Schinkel Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000001b43a806225a026c" From: hamiegold@gmail.com (Hammed Ajao) --0000000000001b43a806225a026c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2024 at 11:20=E2=80=AFPM Mike Schinkel wrote: > On Sep 11, 2024, at 4:43 PM, Hammed Ajao wrote: > > Using WebAssembly (Wasm) for PHP doesn't make much sense. PHP already run= s > on its own virtual machine server-side, so adding another VM (Wasm) would > just introduce unnecessary complexity and overhead. > > > Sorry, but I am going to have to call your assertions ill-informed, at > best. Having one VM does not invalidate the value of a different VM with > very different strengths. > > If using two VMs really made no sense there would not be so many people > running a Lua VM in Java. > I said Wasm for PHP makes little sense. I don't know or care about java + lua. Running Wasm and PHP virtual machines together presents several significant challenges and potential issues: =E2=80=A2 Memory Management and Isolation: Each VM has its own memory model= and garbage collection strategy. Data passing between VMs often requires expensive memory copying. Coordinating garbage collection can lead to memory leaks or crashes if not handled properly. =E2=80=A2 Performance Impacts: Context switching between VMs introduces ove= rhead, especially with frequent interactions. Interoperability can create latency due to data serialization and deserialization. Synchronization issues may arise when one VM needs to wait for the other. =E2=80=A2 Security Concerns: Discrepancies between PHP's more permissive environment and Wasm's stricter sandboxing can create vulnerabilities. The communication layer between VMs could be exploited for cross-VM attacks if not properly secured. =E2=80=A2 Debugging Complexities: Developers must use separate debugging to= ols for each VM. Stack traces spanning two execution contexts can be confusing and hard to interpret. =E2=80=A2 Compatibility and Maintenance: Independent evolution of PHP and W= asm VMs may introduce breaking changes, requiring constant updates to the integration layer. API changes in either environment necessitate adjustments in the integration code. =E2=80=A2 Resource Consumption: Running two VMs simultaneously increases CP= U and memory usage. Longer initialization times may impact applications requiring quick boot times. =E2=80=A2 API and Communication Design: Designing efficient and secure APIs= for inter-VM communication is critical but challenging. Marshaling data between PHP and Wasm adds complexity, especially when different programming languages are involved. > Additionally, would this be the LLVM or Cranelift variant of Wasm? > > > TBD > > > For extensions, Wasm would perform even worse than current > implementations, no matter how it's integrated. Presently, I define > zif_handler function pointers that operate on the current execution frame > and return value, triggered when the engine detects an internal function > (fbc). This approach is as direct as it gets. > > > It is not the performance of integration point but what can be done withi= n > WASM, and that would be able to be done on managed hosts if incorporated > into PHP core. > > As for use of extensions that are not part of core on a managed host, som= e > of us in the USA have a saying that relates: > > "Besides that Mrs. Lincoln, how was the play?" > I don't know what that means. > > Suggesting AssemblyScript, especially in this context, seems illogical. > Have you actually worked with WebAssembly and considered performance > implications, or is this based on theoretical knowledge? > > > Admittedly theoretical. > > Are your objections based on actually working with it, or theoretical too= ? > I work extensively with wasm and have ported/ contributed to porting several libs to wasm. > > Your point about operator overloading doesn't seem valid either. > > > One cannot validly claim validity or lack of validity of an _opinion_. > `seems`. > You can disagree or agree =E2=80=94 as that is how one engages with opini= on =E2=80=94 but > an opinion does not beg a proof. > Then I disagree. > Consider the following: > > ```php > class X { > public function plus(X $that) {} > public function equals(X $that) {} > } > ``` > > In this case, `plus` could represent any behavior, as could `equals`. If = I > wanted to, I could implement `plus` to perform what `equals` does and vic= e > versa. Should we consider methods broken just because their names can be > arbitrary? > > > You are comparing apples and oranges. > > There are very few standardized method names and the number of potential > method names is combinatorially large. There are a very few number of > operators and each has a well-known meaning with numbers or in boolean > expressions, which means that if you use one you have reduced by one the > scarce resource of operators, assuming they are used in a manner were 99 > out of 100 developers would choose to overload them in the same way (vs. > say 60 out of 100.) > > But this is just one concern. Read on for other concerns. > > PHP already distinguishes between comparison operators for objects: > > > It seems them operator overloading is not needed so much then, right? > No, it means we get to have more flexibility since we can focus on overloading `=3D=3D` and keeping `=3D=3D=3D` for strict comparison. > > `=3D=3D=3D` compares object IDs, while `=3D=3D` compares their properties= . Beyond > this, there's little reason to apply an operator to an object directly. W= hy > would you need to call `$user1 + $user2` or similar operations on an > object? > > > Why would you add $money1 + $money2, or more likely $subtotal *(1+ $tax) = + > $shipping? Because it make sense. > That's not my point. If those are all objects, that is currently not valid PHP so why would you write that? If those are all `int` then sure, but you can't do operations on objects unless it has been implemented internally. > > And my opinion is that is makes sense if done in core, but not if done in > userland. Again, my *opinion*. > > What scenario would break by allowing operator overloads? > > > The scenario of reading code and being confused if looking at scalars or > objects, and if objects then being able to find the implementation. The > more unique a method is named, the faster it is to find in a codebase, ev= en > with a really smart IDE like PhpStorm. Now imagine having to search for t= he > implementation of `+`, and not even knowing if there is such an override > for code that is not type-hinted. > So you've never actually used a language with operator overloading and just have a vivid imagination? I have zero issue finding operator overloads in C++ code with vscode (just control + click on the operator and if it's overloaded it will take you to the implementation). At the end of the day it's just a method with a different type of name. > > Basically operator overloading is one of the subsets of features for > writing DSLs and having watched everyone in the Ruby community write thei= r > own DSLs in their projects they ended up with as many different languages > as they had programming teams, and 99% of those languages were incomplete > and poorly designed. > Ruby devs aren't exactly known for making great choices or writing good code, regardless, you should look into the word `anecdotal. > > There is something freeing about constraints and it is just my opinion > that PHP having the constraints that you cannot really write DSLs mean > that people end up more often getting work done rather than writing their > own custom DSL.And operator overloads are in this category for me. > Don't forget to clarify that this is your opinion. > BTW, the first time I realized this was in the early 90's when I compared > Clipper to FoxPro. Clipper was so much more powerful than FoxPro as a > language. I taught Clipper professionally and I wrote a book on it. But > after the end of that phase of my life I looked back on Clipper vs. FoxPr= o > and realized that Clipper developers spent lots of time trying to create > their perfect DSL =E2=80=94 myself included =E2=80=94 but because you cou= ldn't do that in > FoxPro people just really got a lot of shit done with FoxPro. > > However, consider a case where comparing just one property of an object > (like a hash) is enough to determine equality. Wouldn't it be great if, > without changing any of the calling code, the engine compared `$this->has= h > =3D=3D=3D $that->hash` when `$this =3D=3D $that` is invoked, instead of a= ll > properties? > > > No, it would be awful. I would not be able to look at the code and know > what it is actually comparing. > Buddy, I don't think I can explain this to you any better, but try to keep an open mind.` > > And what if I actually want to compare the objects and not the hashes? > What if I did not know the object has an overload for equals and I wrote > code assuming it was comparing objects? > Then you use `=3D=3D=3D` which won't be overloadable because it makes no se= nse to do so. What `=3D=3D` does under the hood isn't really important to you as long as = it satisfies the comparison. > > Without operator overloading, I'd have to define an `equals` method and > replace every `$obj =3D=3D $x` call with `$obj->equals($x)`. > > > IMO doing what you'd "have to" do equates to better software engineering. > Some of us write other programming languages as well. Just because PHP forces me to do this doesn't mean there isn't a better way. In C++ i would just use an operator overload. > > > > Moreover, operator overloading unlocks new possibilities for algorithm > design. For example, you could define complex mathematical operations on > custom objects, enabling you to express algorithms more concisely and > naturally. Imagine implementing vector addition, matrix multiplication, o= r > symbolic computation directly in PHP. Instead of verbose method calls lik= e > `$vec1->add($vec2)` or `$matrix1->multiply($matrix2)`, you could use simp= le > and intuitive syntax like `$vec1 + $vec2` or `$matrix1 * $matrix2`. This = is > particularly useful for domain-specific algorithms where overloading > enhances readability and performance. > > > Not sure if you read all my comments in this or the prior thread, but I > was arguing that there are *some* good use-cases =E2=80=94 ones that coul= d easily > be standardized across all PHP users =E2=80=94 and those use-cases would = make great > features to have in core: vector addition, matrix multiplication, and > symbolic computation fit into those categories IMO. > But what's the point if i have to write an extension to utilize it? So I should never be able to do vector addition, matrix multiplication, and symbolic computation in userland because some people are scared of operators? > > Operator overloading isn't just about convenience. It opens the door to > more expressive algorithms, better readability, and reduces boilerplate > code, all while maintaining backward compatibility with existing PHP > behavior. > > > It opens the door to DSLs which opens the door to allowing every team to > have their own unique DSL, and that is why I am against it. > So you're against ... domain specific languages? And since operators can be used of DSLs, they shouldn't be allowed in userland? > > But listen, I am just voicing my opinion, and I am only voicing it becaus= e > I made a comment about relaxing operators in typedefs and someone claimed > (something like) "that has the same issues as operator overloading" for > which I disagreed. But now because of further replies I have gone really > far down the operator overloading rabbit hole which I had not intended to > go down. > > On this I have a firmly-held opinion based from well over 30 years of > programming experience, so I am really unlikely to change my opinion. But > it is still just my opinion, I don't have a vote anyway, anyone is in the > right to disagree with me, and AFAIK there is not even an active RFC > currently being discussed where the ones 4[1] and 3[2] years ago were bot= h > declined. > > So arguing with me about operator overloading is effectively just tilting > at windmills. If you really want userland operator overloading in PHP so > badly, propose another RFC and everyone who wants it will likely champion > it, I will likely argue against it, but maybe it will finally pass and > you'll get what you want. > > Whatever the case, respectfully, you can disagree with me but please do > not claim my opinion is "invalid" as that is just hubris. > > -Mike > > [1] https://wiki.php.net/rfc/userspace_operator_overloading > [2] https://wiki.php.net/rfc/user_defined_operator_overloads > > --0000000000001b43a806225a026c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 11, 2024 at 11:20=E2=80= =AFPM Mike Schinkel <mike@newclar= ity.net> wrote:
On Sep 11, 2024, at 4:43 PM, Hammed Ajao <hamiegold@gmail.com> wrote:

Using WebAssembly (Wasm) for PHP doesn't= make much sense. PHP already runs on its own virtual machine server-side, = so adding another VM (Wasm) would just introduce unnecessary complexity and= overhead.=C2=A0

Sor= ry, but I am going to have to call your assertions ill-informed, at best.= =C2=A0 Having one VM does not invalidate the value of a different VM with v= ery different strengths.=C2=A0

If using two VMs really made no sense there would not be s= o many people running a Lua VM in Java.

I said Wasm for PHP makes little sense. I don't know or care a= bout java=C2=A0+ lua.=C2=A0

Running Wasm and PHP v= irtual machines together presents several significant challenges and potent= ial issues:

=E2=80=A2 Memory Management and Isolation: Each VM has i= ts own memory model and garbage collection strategy. Data passing between V= Ms often requires expensive memory copying. Coordinating garbage collection= can lead to memory leaks or crashes if not handled properly.
=E2=80=A2 = Performance Impacts: Context switching between VMs introduces overhead, esp= ecially with frequent interactions. Interoperability can create latency due= to data serialization and deserialization. Synchronization issues may aris= e when one VM needs to wait for the other.
=E2=80=A2 Security Concerns: = Discrepancies between PHP's more permissive environment and Wasm's = stricter sandboxing can create vulnerabilities. The communication layer bet= ween VMs could be exploited for cross-VM attacks if not properly secured.=E2=80=A2 Debugging Complexities: Developers must use separate debugging = tools for each VM. Stack traces spanning two execution contexts can be conf= using and hard to interpret.
=E2=80=A2 Compatibility and Maintenance: In= dependent evolution of PHP and Wasm VMs may introduce breaking changes, req= uiring constant updates to the integration layer. API changes in either env= ironment necessitate adjustments in the integration code.
=E2=80=A2 Reso= urce Consumption: Running two VMs simultaneously increases CPU and memory u= sage. Longer initialization times may impact applications requiring quick b= oot times.
=E2=80=A2 API and Communication Design: Designing efficient a= nd secure APIs for inter-VM communication is critical but challenging. Mars= haling data between PHP and Wasm adds complexity, especially when different= programming languages are involved.
=C2=A0
=
=
Additionally, would this be the LLVM or Cranelift variant of Wasm?

TBD


=
=
For extensions, Wasm would perform even worse than current implementat= ions, no matter how it's integrated. Presently, I define zif_handler fu= nction pointers that operate on the current execution frame and return valu= e, triggered when the engine detects an internal function (fbc). This appro= ach is as direct as it gets.
<= br>
It is not the performance of integration point but what can b= e done within WASM, and that would be able to be done on managed hosts if i= ncorporated into PHP core. =C2=A0

As for use of ex= tensions that are not part of core on a managed host, some of us in the USA= have a saying that relates:=C2=A0

=C2=A0"Bes= ides that Mrs. Lincoln, how was the play?" =C2=A0

I don't know what that means.
= =C2=A0

Suggesting AssemblyScript, espec= ially in this context, seems illogical. Have you actually worked with WebAs= sembly and considered performance implications, or is this based on theoret= ical knowledge?

Admi= ttedly theoretical. =C2=A0

Are your objections bas= ed on actually working with it, or theoretical too?

I work extensively with wasm and have ported/ contribu= ted to porting several libs to wasm.
=C2=A0

Your point about operator overloading doesn't seem valid= either.

One canno= t validly claim validity or lack of validity of an _opinion_.=C2=A0=C2=A0

=C2=A0`seems`.
<= br>

<= div style=3D"overflow-wrap: break-word;">

You can d= isagree or agree =E2=80=94 as that is how one engages with opinion =E2=80= =94 but an opinion does not beg a proof.

Then I disagree.
=C2=A0
Consider the following:

```php
class X {
=C2=A0 =C2= =A0 public function plus(X $that) {}
=C2=A0 =C2=A0 public function equal= s(X $that) {}
}
```

In this case, `plus` could represent any b= ehavior, as could `equals`. If I wanted to, I could implement `plus` to per= form what `equals` does and vice versa. Should we consider methods broken j= ust because their names can be arbitrary?

You are comparing apples and oranges. =C2=A0

There are very few standardized method names and the = number of potential method names is combinatorially large. There are a very= few number of operators and each has a well-known meaning with numbers or = in boolean expressions, which means that if you use one you have reduced by= one the scarce resource of operators, assuming they are used in a manner w= ere 99 out of 100 developers would choose to overload them in the same way = (vs. say 60 out of 100.)

But this is just one conc= ern. Read on for other concerns.

PHP already disti= nguishes between comparison operators for objects:

It seems them operator overloading is not ne= eded so much then, right?

No, i= t means we get to have more flexibility since we can focus on overloading `= =3D=3D` and keeping `=3D=3D=3D` for strict comparison.
=C2=A0

`=3D=3D=3D` compares object IDs, while `= =3D=3D` compares their properties. Beyond this, there's little reason t= o apply an operator to an object directly. Why would you need to call `$use= r1 + $user2` or similar operations on an object?=C2=A0

Why would you add $money1 + $money2= , or more likely $subtotal *(1+ $tax) + $shipping?=C2=A0 Because it make se= nse. =C2=A0

That's no= t my point. If those are all objects, that is currently not valid PHP so wh= y would you write that? If those are all `int` then sure, but you can't= do operations on objects unless it has been implemented internally.
<= div>=C2=A0

And my opinion is= that is makes sense if done in core, but not if done in userland.=C2=A0 Ag= ain, my *opinion*.

What scenario would break by allowing operator = overloads?

The scenario o= f reading code and being confused if looking at scalars or objects, and if = objects then being able to find the implementation. The more unique a metho= d is named, the faster it is to find in a codebase, even with a really smar= t IDE like PhpStorm. Now imagine having to search for the implementation of= `+`, and not even knowing if there is such an override for code that is no= t type-hinted.

So you'= ;ve never actually used a language with operator overloading and just have = a vivid imagination? I have zero issue finding operator overloads in C++ co= de with vscode (just control=C2=A0+ click on the operator and if it's o= verloaded it will take you to the implementation). At the end of the day it= 's just a method with a different type of name.=C2=A0

Basically operator overloading is one of the = subsets of features for writing DSLs and having watched everyone in the Rub= y community write their own DSLs in their projects they ended up with as ma= ny different languages as they had programming teams, and 99% of those lang= uages were incomplete and poorly designed. =C2=A0

Ruby devs aren't exactly known for making grea= t choices or writing good code, regardless, you should look into the word `= anecdotal.
=C2=A0

= There is something freeing about constraints and it is just my opinion that= PHP having the constraints that you cannot really write =C2=A0DSLs mean th= at people end up more often getting work done rather than writing their own= custom DSL.And operator overloads are in this category for me.
=

Don't forget to clarify that thi= s is your opinion.


BTW, the first time I realized this was in the early 90's when I = compared Clipper to FoxPro.=C2=A0 Clipper was so much more powerful than Fo= xPro as a language. I taught Clipper professionally and I wrote a book on i= t.=C2=A0 But after the end of that phase of my life I looked back on Clippe= r vs. FoxPro and realized that Clipper developers spent lots of time trying= to create their perfect DSL =E2=80=94 myself included =E2=80=94 but becaus= e you couldn't do that in FoxPro people just really got a lot of shit d= one with FoxPro.

However, consider a case where co= mparing just one property of an object (like a hash) is enough to determine= equality. Wouldn't it be great if, without changing any of the calling= code, the engine compared `$this->hash =3D=3D=3D $that->hash` when `= $this =3D=3D $that` is invoked, instead of all properties?

No, it would be awful.=C2=A0 I wou= ld not be able to look at the code and know what it is actually comparing. = =C2=A0

Buddy, I don't= think I can explain this to you any better, but try to keep an open mind.`=
=C2=A0

And what i= f I actually want to compare the objects and not the hashes? What if I did = not know the object has an overload for equals and I wrote code assuming it= was comparing objects?

T= hen you use `=3D=3D=3D` which won't be overloadable because it makes no= sense to do so.
What `=3D=3D` does under the hood isn't real= ly important to you as long as it satisfies the comparison.
=C2= =A0

Without operator overloading, I= 9;d have to define an `equals` method and replace every `$obj =3D=3D $x` ca= ll with `$obj->equals($x)`.

IMO doing what you'd "have to" do equates to = better software engineering.

<= div>Some of us write other programming languages as well. Just because PHP = forces me to do this doesn't mean there isn't a better way. In C++ = i would just use an operator overload.
=C2=A0
=C2=A0
=C2=A0

Moreo= ver, operator overloading unlocks new possibilities for algorithm design. F= or example, you could define complex mathematical operations on custom obje= cts, enabling you to express algorithms more concisely and naturally. Imagi= ne implementing vector addition, matrix multiplication, or symbolic computa= tion directly in PHP. Instead of verbose method calls like `$vec1->add($= vec2)` or `$matrix1->multiply($matrix2)`, you could use simple and intui= tive syntax like `$vec1 + $vec2` or `$matrix1 * $matrix2`. This is particul= arly useful for domain-specific algorithms where overloading enhances reada= bility and performance.

Not sure if you read all my comments in this or the prior thread, = but I was arguing that there are *some* good use-cases =E2=80=94 ones that = could easily be standardized across all PHP users =E2=80=94 and those use-c= ases would make great features to have in core: vector addition, matrix mul= tiplication, and symbolic computation fit into those categories IMO.
<= /div>

But what's the point if i h= ave to write an extension to utilize it? So I should never be able to do ve= ctor addition, matrix multiplication, and symbolic computation in userland = because some people are scared of operators?

=C2= =A0

Operator overloading isn't jus= t about convenience. It opens the door to more expressive algorithms, bette= r readability, and reduces boilerplate code, all while maintaining backward= compatibility with existing PHP behavior.

It opens the door to DSLs which opens the door to al= lowing every team to have their own unique DSL, and that is why I am agains= t it.

So you're against ...= domain specific languages? And since operators can be used of DSLs, they s= houldn't be allowed in userland?=C2=A0
=C2=A0

But listen, I am just voicing my opinion, an= d I am only voicing it because I made a comment about relaxing operators in= typedefs and someone claimed (something like) "that has the same issu= es as operator overloading" for which I disagreed. But now because of = further replies I have gone really far down the operator overloading rabbit= hole which I had not intended to go down. =C2=A0

= On this I have a firmly-held opinion based from well over 30 years of progr= amming experience, so I am really unlikely to change my opinion. But it is = still just my opinion, I don't have a vote anyway, anyone is in the rig= ht to disagree with me, and AFAIK there is not even an active RFC currently= being discussed where the ones 4[1] and 3[2] years ago were both declined.=
=
=C2=A0
So arguing = with me about operator overloading is effectively just tilting at windmills= .=C2=A0 If you really want userland operator overloading in PHP so badly, p= ropose another RFC and everyone who wants it will likely champion it, I wil= l likely argue against it, but maybe it will finally pass and you'll ge= t what you want.=C2=A0

Whatever the case, respectfully, you can disagree with me but plea= se do not claim my opinion is "invalid" as that is just hubris.

-Mike


--0000000000001b43a806225a026c--