On Wed, Sep 11, 2024 at 11:20 PM Mike Schinkel <m...@newclarity.net> wrote:
> 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.
>
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:
• 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.
• Performance Impacts: Context switching between VMs introduces overhead,
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.
• 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.
• Debugging Complexities: Developers must use separate debugging tools for
each VM. Stack traces spanning two execution contexts can be confusing and
hard to interpret.
• Compatibility and Maintenance: Independent evolution of PHP and Wasm VMs
may introduce breaking changes, requiring constant updates to the
integration layer. API changes in either environment necessitate
adjustments in the integration code.
• Resource Consumption: Running two VMs simultaneously increases CPU and
memory usage. Longer initialization times may impact applications requiring
quick boot times.
• 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 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?"
>
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 — as that is how one engages with opinion — 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 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?
>
No, it means we get to have more flexibility since we can focus on
overloading `==` and keeping `===` for strict comparison.
>
> `===` 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.
>
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, 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.
>
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 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.
>
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. 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.
>
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 `===` which won't be overloadable because it makes no sense to
do so.
What `==` 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 == $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, 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.
>
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 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
> [2] https://wiki.php.net/rfc/user_defined_operator_overloads
>
>
