> On Sep 11, 2024, at 4:43 PM, Hammed Ajao <hamieg...@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.
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.
> 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 within
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, some of
us in the USA have a saying that relates:
"Besides that Mrs. Lincoln, how was the play?"
> 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?
> Your point about operator overloading doesn't seem valid either.
One cannot validly claim validity or lack of validity of an _opinion_.
You can disagree or agree — as that is how one engages with opinion — but an
opinion does not beg a proof.
> 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 vice
> 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?
> `===` compares object IDs, while `==` compares their properties. Beyond this,
> there's little reason to apply an operator to an object directly. Why 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.
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, even with a
really smart 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 not type-hinted.
Basically operator overloading is one of the subsets of features for writing
DSLs and having watched everyone in the Ruby community write their 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.
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.
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. FoxPro and
realized that Clipper developers spent lots of time trying to create their
perfect DSL — myself included — but because you couldn'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->hash ===
> $that->hash` when `$this == $that` is invoked, instead of all properties?
No, it would be awful. I would not be able to look at the code and know what
it is actually comparing.
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?
> Without operator overloading, I'd have to define an `equals` method and
> replace every `$obj == $x` call with `$obj->equals($x)`.
IMO doing what you'd "have to" do equates to better software engineering.
> 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, or
> symbolic computation directly in PHP. Instead of verbose method calls like
> `$vec1->add($vec2)` or `$matrix1->multiply($matrix2)`, you could use simple
> 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 — ones that could easily be
standardized across all PHP users — and those use-cases would make great
features to have in core: vector addition, matrix multiplication, and symbolic
computation fit into those categories IMO.
> 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.
But listen, I am just voicing my opinion, and I am only voicing it because 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 both 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
<https://wiki.php.net/rfc/userspace_operator_overloading>
[2] https://wiki.php.net/rfc/user_defined_operator_overloads
<https://wiki.php.net/rfc/user_defined_operator_overloads>
