[PHP-DEV] Zephir, and other tangents

Mailing Lists php.internals
1

Hi Rowan,

This message is in reply to bikeshed: Typed Aliases - Externals from the thread "bikeshed: Typed Aliases"

On Sep 10, 2024, at 5:35 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
On 10 September 2024 19:32:19 BST, Mike Schinkel <mike@newclarity.net> wrote:

BTW, why has nobody ever mentioned Zephir on this list (that I am aware of?)

Zephir is an interesting idea that has never quite fulfilled its aims. The Phalcon developers hoped that creating a more PHP-like language would allow more people to work on extensions such as their framework, but it doesn't seem to have worked out that way.

The worse problem was that Zephir itself had very few contributors. A few years ago, the project came close to shutting down as there was nobody left to maintain it; Phalcon was to be rewritten in PHP. <https://blog.phalcon.io/post/the-future-of-phalcon&gt; Since then, somebody has stepped up, but Phalcon work is still focussed on the PHP rewrite, with the intention of a smaller, optional, extension providing performance-critical components. <https://blog.phalcon.io/post/phalcon-roadmap&gt;

Thank you for the details about Zephir, as I was not fully aware of its history.

On the surface it looks like a really promising project, it is a shame that more people are not interested in seeing it be successful so that it could be maintained and improved.

BTW, my rhetorical comment asking why nobody mentions it on the list was really an indirect reference to the "Using and Mentioning Third-party Packages" thread[1] I have wanted to comment on but have not had the time to read the full thread and craft an argument that I hope would be compelling to many people.

Meanwhile, PHP 7 and 8 have massively increased both the performance and the capability of code written in PHP, and even FFI to bridge to existing native binaries (although I gather there's a lot that could be improved to make that more useful).
<snip>
...except to say that I think we should be aiming to reduce the difference between what can be done in extensions and what in PHP code, rather than planning any new such differences.

True, but let us split this into two discussions. One discussion you made here which is "make PHP better rather than make ways to extend PHP externally."

The 2nd is the discussion I was having which was more constrained, i.e. "In the case of operator overloading that I argue we should not offer in userland I was exploring the idea of adding internal features that allow extensions to be developed to address those use-cases, and especially for extensions that would be included in core, not necessarily for optional extensions."

Before we address the broad question let us address the narrow one I was focused on.

First, do you think we should add general operator overloading as in C++, Python, C#, Swift, Ruby, Kotlin and Dart, or do you agree that adding it would be opening Pandora's box? If you think we should add operator overloading then we can agree to disagree.

If you agree we should not add then do you agree that we could add operator overloading for specific classes in core, such as if we added a Money or Currency class? Ignore whether you think we should add a Money or Currency class — assume we should — and just answer if you think we should allow operator overloading for classes added to core where we can standardize the operator's meanings across all uses of PHP?

If you've gotten this far and we are still in agreement then I was looking for a way to make it easier to add operator overloading for classes to be added to core. So your comment "to reduce the difference between what can be done in extensions and what in PHP code, rather than planning any new such differences" was really presenting my argument as apples when I was instead discussing oranges. Though I can certainly understand if that was not previously clear to you, hopefully it is now.

(Alternately, for operator overloading, do you see any way in which we could constrain userland operator overloads such that we would not end up many different competing meanings of plus, minus, times, divide, equals, not equals, etc. for similar types of classes? I certainly cannot envision how we could constrain it in a useful way.)

-----------

With that covered I'll respond to your more general argument which I characterized as you advocating to "Make PHP better rather than make ways to extend PHP externally."

Generally, I agree. Where it is possible — and not harmful — to do so, it would be better to make PHP better than to just find ways to extend PHP in other ways.

But let us be realistic and honest with each other. PHP has many strengths but it also has weaknesses that it will never be able to address without changing the essential nature of PHP and without huge BC breakage.

And for those things were PHP is not great — or where we see foot-guns so we explicitly do not want to add to userland — it would make sense to enable PHP to be extended through other means. And *especially* in ways that do not require being in control of the server PHP is running on given how ubiquitous managed hosting has become for many who run PHP apps.

I discussed with you privately several years ago how I thought supporting WebAssembly[2][3] would be huge boon to PHP, and at the time I seem to remember you barely knew about it and were thus dismissive. IMO then and now, supporting WASM in PHP Core would make certain things possible that would only otherwise be possible in extensions written in C or I guess via the FFI in other languages, but make it possible without having control of the server PHP is running on, and in any language that supports WASM.

What things is PHP not great at? Real-time code, not using lots of memory when processing huge data structures, C-levels of performance, and probably a few other things.

The thing is, if we allow people to extend PHP in other ways and PHP is just as good as extending in those other ways, people will almost universally default to using PHP. So I don't see danger in harming PHP by enabling PHP to be extended in other languages for those things PHP is not good at.

The overall trend is to have only what's absolutely necessary in an extension.

Not sure what you mean here. When I say "extension in core" I mean an extension that ships with core. If that is a trend to move away from for some reason then substitute "in core" for every place I wrote "an extension in core." Effectively that point is red herring for the point I was trying to make.

and there have even been suggestions that some built-in functions would be better off implemented in PHP itself, if the right low-level features were included.

Now implementing PHP in PHP — assuming I understand what you mean — is something I have been wanting and occasionally mentioning for years.

Specifically I think it would make great sense to have some of the standard library that ships in core to be written in PHP which would open up the ability for more people to contribute to PHP core taking some burden off the maintainers of core who program in C, and would mean that every improvement in the C part of PHP would make all the PHP parts of PHP better. Is that what you meant?

If yes, want to collaborate on an RFC? I know at least a few others who would jump at the change to pursue this.

-Mike

[1] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects - Externals
[2] WebAssembly - Wikipedia
[3] https://webassembly.org/

2

On 11 September 2024 03:57:23 BST, Mike Schinkel <mike@newclarity.net> wrote:

If you've gotten this far and we are still in agreement then I was looking for a way to make it easier to add operator overloading for classes to be added to core. So your comment "to reduce the difference between what can be done in extensions and what in PHP code, rather than planning any new such differences" was really presenting my argument as apples when I was instead discussing oranges. Though I can certainly understand if that was not previously clear to you, hopefully it is now.

Perhaps you're unaware that classes in core already can, and do, provide operator overloading. GMP is the "poster child" for it, overloading a bunch of mathematical operators, but the mechanism it uses to do so is reasonably straightforward and available to any extension.

I've never liked that approach, because it means users can't write polyfills, or even stub objects, that have these special behaviours. It feels weird for the language to define behaviour that isn't expressible in the language.

It also risks conflicting with a future language feature that overlaps, as happened with all native functions marked as accepting string automatically coercing nulls, but all userland ones rejecting it. Deprecating that difference has caused a lot of friction.

And for those things were PHP is not great — or where we see foot-guns so we explicitly do not want to add to userland — it would make sense to enable PHP to be extended through other means. And *especially* in ways that do not require being in control of the server PHP is running on given how ubiquitous managed hosting has become for many who run PHP apps.

This is the tricky part for me: some of the things people want to do in extensions are explicitly the kinds of thing a shared host would not want them to, such as interface to system libraries, perform manual memory management, interact with other processes on the host.

I discussed with you privately several years ago how I thought supporting WebAssembly[2][3] would be huge boon to PHP, and at the time I seem to remember you barely knew about it and were thus dismissive.

If WASM can provide some kind of sandbox, while still allowing a good portion of the features people actually want to write in extensions, I can imagine that being useful. But how exactly that would work I have no idea, so can't really comment further.

The overall trend is to have only what's absolutely necessary in an extension.

Not sure what you mean here.

I mean, like Phalcon plans to, ship both a binary extension and a PHP library, putting only certain essential functionality in the extension. It's how MongoDB ships their PHP bindings, for instance - the extension provides low-level protocol support which is not intended for every day use; the library is then free to evolve the user-facing parts more freely.

Regards,
Rowan Tommins
[IMSoP]

3

Hi Rowan,

On Sep 11, 2024, at 2:55 AM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
Perhaps you're unaware that classes in core already can, and do, provide operator overloading. GMP is the "poster child" for it, overloading a bunch of mathematical operators, but the mechanism it uses to do so is reasonably straightforward and available to any extension.

I was making an (evidently) uninformed assuming that it was non-trivial to add operator overloading at the C level. If it is easy, then my comments were moot.

That said, writing extensions in C and deploying them is non-trivial —comparing to writing code in PHP— so there is that. ¯\_(ツ)_/¯

I've never liked that approach, because it means users can't write polyfills, or even stub objects, that have these special behaviours. It feels weird for the language to define behaviour that isn't expressible in the language.

Understood. In _general_ I don't like it either, but I will use as an analogy a prior discussion regarding __toArray, and I quote[1]:

"For the "convertible to array" case, I think __toArray, or an interface specifying just that one method, would make more sense than combining it with the existing interfaces. I'm sceptical of that concept, though, because most objects could be converted to many different arrays in different circumstances, each of which should be given a different and descriptive name."

I am of course quoting you.

Similarly, operators could mean different things, e.g. it is possible to have different meaning of equal, and even different meanings of plus. Or worse be applied in ways that are non-sensical to anybody but the developer who implements them (that would be the same kind of developer who names their variables after Game of Thrones characters.)

That is why I am not a fan of operator overloading, just as you were not a fan of __toArray which to me is less problematic than overloaded operators because it has such smaller scope and is actually quote useful for a common set of use-cases regardless of the potential for confusion. But I digress.

It also risks conflicting with a future language feature that overlaps, as happened with all native functions marked as accepting string automatically coercing nulls, but all userland ones rejecting it. Deprecating that difference has caused a lot of friction.

That is a little different in that it was a behavior that occurred in both core and userland whereas only allowing operator overloading in core would mean there would be not userland differences that could conflict.

Whatever the case, if there are only two options: 1.) no operator overloading, and 2.) userland operator overloading I would far prefer the former.

This is the tricky part for me: some of the things people want to do in extensions are explicitly the kinds of thing a shared host would not want them to, such as interface to system libraries, perform manual memory management, interact with other processes on the host.

If WASM can provide some kind of sandbox, while still allowing a good portion of the features people actually want to write in extensions, I can imagine that being useful. But how exactly that would work I have no idea, so can't really comment further.

WebAssembly has a deny-by-default design so could be something to seriously consider for extensibility in PHP. Implementations start with a full sandbox[2] and only add what they need to avoid those kinds of concerns.

Also, all memory manipulations sandboxed, though there are still potential vulnerabilities within the sandbox so the project that incorporates WASM needs to be careful. WASM written in C/C++ can have memory issues just like in regular C/C++, for example. One option would be to allow only AssemblyScript source for WASM. Another would be a config option that a web-host could set to only allow signed modules, but that admittedly would open another can of worms. But the memory issues cannot leak out of the module or affect other modules nor the system, if implemented with total memory constraints.

That said, web hosts can't stop PHP developers from creating infinite loops so the memory issues with WASM don't feel like too much bigger of a concern given their sandboxed nature. I've copied numerous other links for reference: [4][5][6]

The overall trend is to have only what's absolutely necessary in an extension.

Not sure what you mean here.

I mean, like Phalcon plans to, ship both a binary extension and a PHP library, putting only certain essential functionality in the extension. It's how MongoDB ships their PHP bindings, for instance - the extension provides low-level protocol support which is not intended for every day use; the library is then free to evolve the user-facing parts more freely.

Gotcha.

I think that actually supports what I was saying; people would gravitate to only doing in an extension what they cannot do in PHP itself, and over time if PHP itself improves there is reason to migrate more code to PHP.

But there can still be reasons to not allow some thing in userland. Some things like __toArray.

-Mike

[1] Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface
[2] https://thenewstack.io/how-webassembly-offers-secure-development-through-sandboxing/
[3] A practical guide to WebAssembly memory - radu's blog
[4] CMU CSD PhD Blog - Provably-Safe Sandboxing with WebAssembly
[5] ChatGPT
[6] https://www.assemblyscript.org/

4

On Wed, Sep 11, 2024 at 1:13 PM Mike Schinkel <mike@newclarity.net> wrote:

Hi Rowan,

On Sep 11, 2024, at 2:55 AM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
Perhaps you’re unaware that classes in core already can, and do, provide operator overloading. GMP is the “poster child” for it, overloading a bunch of mathematical operators, but the mechanism it uses to do so is reasonably straightforward and available to any extension.

I was making an (evidently) uninformed assuming that it was non-trivial to add operator overloading at the C level. If it is easy, then my comments were moot.

That said, writing extensions in C and deploying them is non-trivial —comparing to writing code in PHP— so there is that. ¯_(ツ)_/¯

I’ve never liked that approach, because it means users can’t write polyfills, or even stub objects, that have these special behaviours. It feels weird for the language to define behaviour that isn’t expressible in the language.

Understood. In general I don’t like it either, but I will use as an analogy a prior discussion regarding __toArray, and I quote[1]:

“For the “convertible to array” case, I think __toArray, or an interface specifying just that one method, would make more sense than combining it with the existing interfaces. I’m sceptical of that concept, though, because most objects could be converted to many different arrays in different circumstances, each of which should be given a different and descriptive name.”

I am of course quoting you.

Similarly, operators could mean different things, e.g. it is possible to have different meaning of equal, and even different meanings of plus. Or worse be applied in ways that are non-sensical to anybody but the developer who implements them (that would be the same kind of developer who names their variables after Game of Thrones characters.)

That is why I am not a fan of operator overloading, just as you were not a fan of __toArray which to me is less problematic than overloaded operators because it has such smaller scope and is actually quote useful for a common set of use-cases regardless of the potential for confusion. But I digress.

It also risks conflicting with a future language feature that overlaps, as happened with all native functions marked as accepting string automatically coercing nulls, but all userland ones rejecting it. Deprecating that difference has caused a lot of friction.

That is a little different in that it was a behavior that occurred in both core and userland whereas only allowing operator overloading in core would mean there would be not userland differences that could conflict.

Whatever the case, if there are only two options: 1.) no operator overloading, and 2.) userland operator overloading I would far prefer the former.

This is the tricky part for me: some of the things people want to do in extensions are explicitly the kinds of thing a shared host would not want them to, such as interface to system libraries, perform manual memory management, interact with other processes on the host.

If WASM can provide some kind of sandbox, while still allowing a good portion of the features people actually want to write in extensions, I can imagine that being useful. But how exactly that would work I have no idea, so can’t really comment further.

WebAssembly has a deny-by-default design so could be something to seriously consider for extensibility in PHP. Implementations start with a full sandbox[2] and only add what they need to avoid those kinds of concerns.

Also, all memory manipulations sandboxed, though there are still potential vulnerabilities within the sandbox so the project that incorporates WASM needs to be careful. WASM written in C/C++ can have memory issues just like in regular C/C++, for example. One option would be to allow only AssemblyScript source for WASM. Another would be a config option that a web-host could set to only allow signed modules, but that admittedly would open another can of worms. But the memory issues cannot leak out of the module or affect other modules nor the system, if implemented with total memory constraints.

That said, web hosts can’t stop PHP developers from creating infinite loops so the memory issues with WASM don’t feel like too much bigger of a concern given their sandboxed nature. I’ve copied numerous other links for reference: [4][5][6]

The overall trend is to have only what’s absolutely necessary in an extension.

Not sure what you mean here.

I mean, like Phalcon plans to, ship both a binary extension and a PHP library, putting only certain essential functionality in the extension. It’s how MongoDB ships their PHP bindings, for instance - the extension provides low-level protocol support which is not intended for every day use; the library is then free to evolve the user-facing parts more freely.

Gotcha.

I think that actually supports what I was saying; people would gravitate to only doing in an extension what they cannot do in PHP itself, and over time if PHP itself improves there is reason to migrate more code to PHP.

But there can still be reasons to not allow some thing in userland. Some things like __toArray.

-Mike

[1] https://www.mail-archive.com/internals@lists.php.net/msg100001.html
[2] https://thenewstack.io/how-webassembly-offers-secure-development-through-sandboxing/
[3] https://radu-matei.com/blog/practical-guide-to-wasm-memory/
[4] https://www.cs.cmu.edu/~csd-phd-blog/2023/provably-safe-sandboxing-wasm/
[5] https://chatgpt.com/share/b890aede-1c82-412a-89a9-deae99da506e
[6] https://www.assemblyscript.org/

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. Additionally, would this be the LLVM or Cranelift variant of Wasm?

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.

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?

Your point about operator overloading doesn’t seem valid either. Consider the following:

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?

PHP already distinguishes between comparison operators for objects:

<?php
$obj1 = $obj2 = new stdclass;
assert($obj1 === $obj2); // compares object IDs
assert($obj1 == $obj2); // compares properties
$obj1 = new stdclass;
assert($obj1 !== $obj2);
assert($obj1 == $obj2);

=== 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? What scenario would break by allowing operator overloads?

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? Without operator overloading, I’d have to define an equals method and replace every $obj == $x call with $obj->equals($x).

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.

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.

Cheers,
Hammed.

5

On 11 September 2024 20:12:53 BST, Mike Schinkel <mike@newclarity.net> wrote:

It also risks conflicting with a future language feature that overlaps, as happened with all native functions marked as accepting string automatically coercing nulls, but all userland ones rejecting it. Deprecating that difference has caused a lot of friction.

That is a little different in that it was a behavior that occurred in both core and userland whereas only allowing operator overloading in core would mean there would be not userland differences that could conflict.

Historically, that's what we had for scalar parameters. All the way back in PHP 4 (I think), the engine had a function called "zend_parse_parameters" (ZPP), which took the PHP values a user provided, and either converted them to the desired C type, or rejected them. In effect, it allowed functions defined in extensions to declare scalar typed parameters.

Then in PHP 7, we added scalar type declarations for parameters in userland functions, and had to work out how they fitted with those internal functions. Part of the motivation for the strict_types toggle was to manage their behaviour; and userland functions require explicit nullable types, whereas ZPP historically coerced nulls regardless.

Anything we let extensions do could end up with the same dilemma later: do we match userland to existing extension behaviour, change extension behaviour, or live with an awkward inconsistency?

WebAssembly has a deny-by-default design so could be something to seriously consider for extensibility in PHP. Implementations start with a full sandbox[2] and only add what they need to avoid those kinds of concerns.

The problem is that second part: in order to be useful for writing a PHP extension, what would we need to let through the sandbox?

For some simple extensions, the equivalent of FFI would be enough: call this special function, and some code runs in the sandbox and spits out an answer.

For others, you need something that's easier to trust than a native binary, but also integrates tightly into the language to do things PHP code can't do. Maybe it's possible, but how is not obvious to me.

I think that actually supports what I was saying; people would gravitate to only doing in an extension what they cannot do in PHP itself, and over time if PHP itself improves there is reason to migrate more code to PHP.

But there can still be reasons to not allow some thing in userland. Some things like __toArray.

I think there's ideas pulling in opposite directions here: on the one hand, using the difficulty of building extensions as a deliberate "speed bump" to avoid people using features "badly"; but on the other hand, wanting to reduce the difficulty of building extensions.

I think the latter is a more noble goal, and one way to help is to make it less *necessary* to build extensions, by adding to the core language the things you currently need extensions to do. Things like efficient string buffers and binary stream manipulation, or attributes and magic methods to override object behaviour.

Regards,
Rowan Tommins
[IMSoP]

6

On Sep 11, 2024, at 4:55 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

On 11 September 2024 20:12:53 BST, Mike Schinkel <mike@newclarity.net> wrote:

It also risks conflicting with a future language feature that overlaps, as happened with all native functions marked as accepting string automatically coercing nulls, but all userland ones rejecting it. Deprecating that difference has caused a lot of friction.

That is a little different in that it was a behavior that occurred in both core and userland whereas only allowing operator overloading in core would mean there would be not userland differences that could conflict.

Historically, that’s what we had for scalar parameters. All the way back in PHP 4 (I think), the engine had a function called “zend_parse_parameters” (ZPP), which took the PHP values a user provided, and either converted them to the desired C type, or rejected them. In effect, it allowed functions defined in extensions to declare scalar typed parameters.

Then in PHP 7, we added scalar type declarations for parameters in userland functions, and had to work out how they fitted with those internal functions. Part of the motivation for the strict_types toggle was to manage their behaviour; and userland functions require explicit nullable types, whereas ZPP historically coerced nulls regardless.

Anything we let extensions do could end up with the same dilemma later: do we match userland to existing extension behaviour, change extension behaviour, or live with an awkward inconsistency?

There are several levels of hypotheticals in your stated concern, so yes, if we make all regrettable decisions then we possibly have a problem. But if we allow several levels of hypotheticals to be criteria for every decision we make then we can probably find an argument against any improvement.

That said, not doing this seems to matter more to you than doing it matters to me, so I relent.

WebAssembly has a deny-by-default design so could be something to seriously consider for extensibility in PHP. Implementations start with a full sandbox[2] and only add what they need to avoid those kinds of concerns.

The problem is that second part: in order to be useful for writing a PHP extension, what would we need to let through the sandbox?

Initially, only scalar parameters and scalar return values. (Stop and contemplate this for a moment, please.)

Then we can consider “letting through” more in future RFCs as we all learn more about using WASM and so that each thing we add can be well considered.

I think that actually supports what I was saying; people would gravitate to only doing in an extension what they cannot do in PHP itself, and over time if PHP itself improves there is reason to migrate more code to PHP.

But there can still be reasons to not allow some thing in userland. Some things like __toArray.

I think there’s ideas pulling in opposite directions here: on the one hand, using the difficulty of building extensions as a deliberate “speed bump” to avoid people using features “badly”; but on the other hand, wanting to reduce the difficulty of building extensions.

That is one way to look at it, but not the only way and not the way I was looking at it.

Let’s say the effort to write something in PHP is 1 and the effort to write in C is 100 using arbitrary units where 100 means almost nobody ever does it. My argument considers 100 being too high a bar, but maybe 50 or 25 is low enough so as to not open the floodgates but still make it easy enough that people actually do it occasionally as clearly even 25 is many times harder than 1.

And no need to bikeshed those numbers. I was using arbitrary numbers to try and illustrate a concept, nothing more.

BTW, I was not looking at it as a “speed bump,” I was looking at it as the fact that features in core are written in C, not PHP.

I think the latter is a more noble goal, and one way to help is to make it less necessary to build extensions, by adding to the core language the things you currently need extensions to do. Things like efficient string buffers and binary stream manipulation, or attributes and magic methods to override object behaviour.

That is one way to consider it, and one I would definitely like to see.

But I still do not think you can optimize out all need for low level languages by adding userland features.

For example, how do we add a feature that allows for efficient looping? Certainly we can optimize the loops themselves; we already have with functions like array_map(), but there would still be need to context switch between C and PHP callable and zvals. That context switching is probably at least an order of magnitude more time consuming than a pure single loop iteration and memory location update in WASM, C, etc. Or do you envision some way to optimize running code in loops, and storage and access of data in byte arrays for which I am not seeing?

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on shared hosts for things that are just not possible in PHP as described a few paragraphs prior, and where we could enhance functionality over time,

  2. Constantly improving PHP the language, which is what you are solely advocating for over extensibility,

  3. Enabling some parts of core — definitely some newer functions and classes, and maybe some existing ones — to be implemented in userland PHP that would ship embedded in PHP core to make maintenance easier and enable more people to potentially contribute to core,

  4. Allow operator overloading for classes in core where the community agrees it makes sense, but if that is a bridge too far then I would be happy if we never allow operator overloading at all, and

  5. Typedefs FTW!

-Mike

7

On 11.09.2024 at 22:43, Hammed Ajao wrote:

Your point about operator overloading doesn't seem valid either. Consider
the following:

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?

PHP already distinguishes between comparison operators for objects:

<?php
$obj1 = $obj2 = new stdclass;
assert($obj1 === $obj2); // compares object IDs
assert($obj1 == $obj2);  // compares properties
$obj1 = new stdclass;
assert($obj1 !== $obj2);
assert($obj1 == $obj2);

`===` 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? What scenario would break by allowing operator overloads?

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? Without operator overloading, I'd have to define an `equals`
method and replace every `$obj == $x` call with `$obj->equals($x)`.

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.

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.

I fully agree, but note that at least two RFCs regarding userland
operator overloading have been declined[1][2], and from what I remember
at least partially because the feature could be "misused".

[1] <PHP: rfc:user_defined_operator_overloads;
[2] <PHP: rfc:userspace_operator_overloading;

Christoph

8

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.

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:

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
[2] https://wiki.php.net/rfc/user_defined_operator_overloads

9

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on
    shared hosts for things that are just not possible in PHP as described a
    few paragraphs prior, and where we could enhance functionality over time,

  2. Constantly improving PHP the language, which is what you are solely
    advocating for over extensibility,
    Hi Mike,

I’m Adam, I’m building WordPress Playground [1] – it’s WordPress running in the browser via a WebAssembly PHP build [2]. I’m excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on
    shared hosts for things that are just not possible in PHP as described a
    few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we’re recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format’s specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it’s unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

  1. Constantly improving PHP the language, which is what you are solely
    advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There’s an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won’t change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn’t affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I’m sceptical this could work with reasonable speed and resource consumption, but let’s assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here’s a few interesting “WASM in PHP” projects I found – maybe they would be helpful:

[1] https://github.com/WordPress/wordpress-playground/
[2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile
[3] https://developer.wordpress.org/reference/classes/wp_html_processor/
[4] https://github.com/WordPress/wordpress-develop/pull/6713
[5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php
[6] https://github.com/WordPress/sqlite-database-integration/pull/157
[7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php
[8] https://security.snyk.io/research/zip-slip-vulnerability

-Adam

10

On Sep 17, 2024, at 8:57 AM, Adam Zielinski <adam.zielinski@automattic.com> wrote:

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on
    shared hosts for things that are just not possible in PHP as described a
    few paragraphs prior, and where we could enhance functionality over time,

  2. Constantly improving PHP the language, which is what you are solely
    advocating for over extensibility,
    Hi Mike,

I’m Adam, I’m building WordPress Playground [1] – it’s WordPress running in the browser via a WebAssembly PHP build [2]. I’m excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on
    shared hosts for things that are just not possible in PHP as described a
    few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we’re recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format’s specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it’s unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

  1. Constantly improving PHP the language, which is what you are solely
    advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There’s an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won’t change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn’t affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I’m sceptical this could work with reasonable speed and resource consumption, but let’s assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here’s a few interesting “WASM in PHP” projects I found – maybe they would be helpful:

[1] https://github.com/WordPress/wordpress-playground/
[2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile
[3] https://developer.wordpress.org/reference/classes/wp_html_processor/
[4] https://github.com/WordPress/wordpress-develop/pull/6713
[5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php
[6] https://github.com/WordPress/sqlite-database-integration/pull/157
[7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php
[8] https://security.snyk.io/research/zip-slip-vulnerability

Thanks for this. It is super great information.

Want to work on an RFC?

-Mike

11

On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote:

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Hi Mike,

I’m Adam, I’m building WordPress Playground [1] – it’s WordPress running in the browser via a WebAssembly PHP build [2]. I’m excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we’re recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format’s specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it’s unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There’s an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won’t change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn’t affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I’m sceptical this could work with reasonable speed and resource consumption, but let’s assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here’s a few interesting “WASM in PHP” projects I found – maybe they would be helpful:

[1] https://github.com/WordPress/wordpress-playground/

[2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile

[3] https://developer.wordpress.org/reference/classes/wp_html_processor/

[4] https://github.com/WordPress/wordpress-develop/pull/6713

[5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php

[6] https://github.com/WordPress/sqlite-database-integration/pull/157

[7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php

[8] https://security.snyk.io/research/zip-slip-vulnerability

-Adam

Hey Adam,

I actually went down something like this road for a bit when working at Automattic. My repo even probably still exists in the graveyard repository… but I had plugins running in C# and Java over a couple of weeks. This was long before wasm was a thing, and while cool, nobody really could think of a use for it.

It seems like you have a use for it though, and I’m reasonably certain you could get it working over ffi in a few weeks; yet you mention hosts not even having the curl extension installed, so I doubt that even if wasm came to be, it would be available on those hosts.

However, plugins basically work via hooks/filters. So as long as you register the right listeners and handle serialization properly, you can simply run a separate process for the plugin, or call a socket for “remote” plugins.

I don’t see anything stopping anyone from implementing that today.

— Rob

12

On Wed, Sep 11, 2024 at 11:20 PM Mike Schinkel <mike@newclarity.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.

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:

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

13

On Sep 17, 2024, at 2:03 PM, Rob Landers rob@bottled.codes wrote:

On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote:

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Hi Mike,

I’m Adam, I’m building WordPress Playground [1] – it’s WordPress running in the browser via a WebAssembly PHP build [2]. I’m excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we’re recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format’s specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it’s unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There’s an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won’t change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn’t affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I’m sceptical this could work with reasonable speed and resource consumption, but let’s assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here’s a few interesting “WASM in PHP” projects I found – maybe they would be helpful:

[1] https://github.com/WordPress/wordpress-playground/

[2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile

[3] https://developer.wordpress.org/reference/classes/wp_html_processor/

[4] https://github.com/WordPress/wordpress-develop/pull/6713

[5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php

[6] https://github.com/WordPress/sqlite-database-integration/pull/157

[7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php

[8] https://security.snyk.io/research/zip-slip-vulnerability

-Adam

Hey Adam,

I actually went down something like this road for a bit when working at Automattic. My repo even probably still exists in the graveyard repository… but I had plugins running in C# and Java over a couple of weeks. This was long before wasm was a thing, and while cool, nobody really could think of a use for it.

It seems like you have a use for it though, and I’m reasonably certain you could get it working over ffi in a few weeks; yet you mention hosts not even having the curl extension installed, so I doubt that even if wasm came to be, it would be available on those hosts.

There are two major areas I have found that would benefit from having a WASM runtime in PHP:

Obviously, being able to run the same algorithms on the frontend and backend is a huge win for consistency in applications. Particularly with text-related algorithms it’s really easy for inconsistencies to develop due to the features available in each languages standard library, as well as due to differences in how each language handles and processes string.

The other major area is similar, and we’ve seen this with the HTML and XML parsing work recently undertaken in WordPress. There are plenty of cases where efficient and spec-compliant operations are valuable, but these kinds of things tend to cost significantly more in user-space PHP. Being able to jump into WASM, even with the overhead of exchanging that data and running another VM, would very likely result in a noticeable net improvement in runtime performance. Additionally, it’s a perk being able to write such algorithms in languages that aid that development through more powerful type systems.

There’s additional value in a number of other separate tasks. Converting images or generating thumbnails is a good example where raw performance is less of a concern than being able to ensure that the image library is available and not exposing the host system to risk. I imagine plenty of “PHP lite-extensions” appearing in this space because it would give people the opportunity to experiment with features that are impractical in user-space PHP before fully committing the language itself to that interface or library. It would extend the reach of PHP’s usability because it would make possible for folks, who happen to be running on cheap shared hosts, to run more complicated processing tasks than are practical today. While big software shops and SaaS vendors do and can run their own custom PHP extensions, there’s not great way to share those generally to people without the same full control over their stack.

However, plugins basically work via hooks/filters. So as long as you register the right listeners and handle serialization properly, you can simply run a separate process for the plugin, or call a socket for “remote” plugins.

I don’t see anything stopping anyone from implementing that today.

— Rob

I’m excited to see this conversation. I’ve wanted to propose it a number of times myself.

Warmly,
Dennis Snell

14

On Tue, Sep 17, 2024 at 9:17 PM Mike Schinkel <mike@newclarity.net> wrote:

On Sep 17, 2024, at 8:57 AM, Adam Zielinski <adam.zielinski@automattic.com> wrote:

> To summarize, I think PHP would benefit from:
>
> 1. Adding WASM for simple low-level extensibility that could run on
> shared hosts for things that are just not possible in PHP as described a
> few paragraphs prior, and where we could enhance functionality over time,
>
> 2. Constantly improving PHP the language, which is what you are solely
> advocating for over extensibility,
Hi Mike,

I’m Adam, I'm building WordPress Playground [1] – it's WordPress running in the browser via a WebAssembly PHP build [2]. I'm excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

> To summarize, I think PHP would benefit from:
>
> 1. Adding WASM for simple low-level extensibility that could run on
> shared hosts for things that are just not possible in PHP as described a
> few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we're recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format's specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it's unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

> 2. Constantly improving PHP the language, which is what you are solely
> advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There's an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won't change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn't affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I'm sceptical this could work with reasonable speed and resource consumption, but let's assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here's a few interesting "WASM in PHP" projects I found – maybe they would be helpful:
- WebAssembly runtime built in PHP (!) GitHub - jasperweyne/unwasm: Transpile webassembly bytecode to PHP and run it
- WebAssembly runtime as a PHP language extension: GitHub - veewee/ext-wasm: Run webassembly from PHP
- WebAssembly runtime as a PHP language extension: GitHub - extism/php-sdk: Extism PHP Host SDK - easily run WebAssembly modules / plugins from PHP applications

[1] GitHub - WordPress/wordpress-playground: Run WordPress in the browser via WebAssembly PHP
[2] wordpress-playground/packages/php-wasm/compile at trunk · WordPress/wordpress-playground · GitHub
[3] WP_HTML_Processor – Class | Developer.WordPress.org
[4] Add WP_XML_Tag_Processor and WP_XML_Processor by adamziel · Pull Request #6713 · WordPress/wordpress-develop · GitHub
[5] blueprints-library/src/WordPress/Zip/ZipStreamReader.php at 87afea1f9a244062a14aeff3949aae054bf74b70 · WordPress/blueprints-library · GitHub
[6] Exhaustive MySQL Parser by adamziel · Pull Request #157 · WordPress/sqlite-database-integration · GitHub
[7] blueprints-library/src/WordPress/AsyncHttp/Client.php at trunk · WordPress/blueprints-library · GitHub
[8] Zip Slip Vulnerability | Snyk

Thanks for this. It is super great information.

Want to work on an RFC?

-Mike

I'm happy to work together on the RFC document. I won't be able to
help with the implementation, though, which makes me nervous about
this part of the "How To Create an RFC" page:

If you don't have the skills to fully implement your RFC and no-one volunteers to code it, there is little chance your RFC will be successful.

I know Steve Manuel from Dylibso [1] was highly interested in building
WASM support for PHP core. He's the founder of Extism [2] and his team
integrated a WASM runtime with PHP using FFI [3]. There's a conference
recording where he does a live demo of running WASM modules as
WordPress plugins [4]. He might be a better person to create an RFC
with, as he also seemed keen to work on the implementation. I've
reached out to him about this discussion.

[1] https://dylibso.com/
[2] https://extism.org/
[3] GitHub - extism/php-sdk: Extism PHP Host SDK - easily run WebAssembly modules / plugins from PHP applications
[4] https://www.youtube.com/watch?v=ChZpveTipPU&themeRefresh=1 (I
think it was that one)

15

On Tue, 17 Sep 2024, at 22:03, Rob Landers wrote:

It seems like you have a use for it though, and I’m reasonably certain you could get it working over ffi in a few weeks; yet you mention hosts not even having the curl extension installed, so I doubt that even if wasm came to be, it would be available on those hosts.

I just want to highlight this point, and clear up some possible misconceptions.

PHP is a modular application, built out of a core engine and any number of “extensions”.

About 60 extensions are in the php-src repository’s ext/ folder. This mostly just means that they are released on the same schedule as PHP, and some simple maintenance tasks are carried out in bulk across them. It also makes it slightly more likely that package managers will include packages for them, but this is not a hard rule - e.g. Ubuntu ships packages for many common PECL and externally-hosted extensions like DS and MongoDB.

A very small number of extensions are “always available” - you can’t build PHP without them. These need to be usable on every platform PHP can be built for, and any external dependencies are generally copied into the php-src repository, rather than increasing the base requirements to build or run a minimal PHP.

I’m pretty confident that an integration of WASM would be a new extension, and it would be optional. So a cheap host that does not enable something as well-known and long-established as ext/curl is extremely unlikely to enable an “ext/wasm”.

A slightly more knowledgeable host might be willing to enable an “ext/wasm”, but not allow a user to upload their own extensions or enable ext/ffi - but only once it had been proven stable and secure…

It appears there are already a couple of projects building WASM extensions. I would urge those of you interested to collaborate on one of those projects. The only reason to raise an RFC would be a) if the extension needed some non-trivial change to the core engine to hook into; or b) if the extension was mature, and it seemed beneficial to move it into the php-src repository rather than releasing it separately.

Regards,

–

Rowan Tommins

[IMSoP]

16

On Wed, Sep 18, 2024 at 2:39 AM Hammed Ajao <hamiegold@gmail.com> wrote:

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.

While these are definitely challenges, aren't they largely the same
for most languages intending to support WebAssembly?

– Adam

17

On Wed, Sep 18, 2024, 5:16 a.m. Adam Zielinski <adam.zielinski@automattic.com> wrote:

On Wed, Sep 18, 2024 at 2:39 AM Hammed Ajao <hamiegold@gmail.com> wrote:

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.

While these are definitely challenges, aren’t they largely the same
for most languages intending to support WebAssembly?

– Adam

Yes and no. The primary goal of WebAssembly is to support high-performance applications on web pages. The premise is simple: JavaScript is the only language natively supported by browsers, but developers want to use various other languages (e.g., C, C++, Rust), particularly for performance-critical tasks. WebAssembly allows code written in these languages to be compiled to a universal format (Wasm) that browsers can run efficiently.

However, in the case of PHP, many of the benefits that WebAssembly brings to other languages are already available through PHP extensions or FFI for non-performance-sensitive tasks. Integrating a Wasm runtime into PHP would be a complex undertaking with significant risks, but it wouldn’t necessarily provide proportionate rewards, which is the main point I’m trying to make.

Extensions, which are already implemented in lower-level languages like C or C++, would still need to be compiled to WebAssembly if the goal were full compatibility. This might lead us down the path of either creating a domain-specific language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to the library authors to choose lower-level languages (as is currently the case).

In essence, WebAssembly is great for certain scenarios, but PHP has existing mechanisms that make the addition of a Wasm runtime potentially redundant for most use cases.

Best,
Hammed

18

On Sep 18, 2024, at 3:09 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
Yes and no. The primary goal of WebAssembly is to support high-performance applications on web pages. The premise is simple: JavaScript is the only language natively supported by browsers, but developers want to use various other languages (e.g., C, C++, Rust), particularly for performance-critical tasks. WebAssembly allows code written in these languages to be compiled to a universal format (Wasm) that browsers can run efficiently.

Yeah. That was the original goal.

But to say WASM's domain is limited to browsers is not valid any longer:

- WebAssembly in the Server | WebAssembly Guide
- How to Implement WebAssembly in Server-Side Applications
- WebAssembly on the server-side. WebAssembly (WASM) is becoming a… | by Michael Yuan | Wasm | Medium
- 🚀 WebAssembly is the perfect runtime for server-side (or serverless) applications
- Server-side WebAssembly prepares for takeoff in 2023 | TechTarget

And even:

- Wasm workloads (Beta) | Docker Docs

However, in the case of PHP, many of the benefits that WebAssembly brings to other languages are already available through PHP extensions or FFI for non-performance-sensitive tasks. Integrating a Wasm runtime into PHP would be a complex undertaking with significant risks, but it wouldn't necessarily provide proportionate rewards, which is the main point I'm trying to make.

Many of the benefits, but NOT the most important one for a large number of installations.

The benefit that neither FFI nor extensions can touch is the ability to be run on a managed server. Without that, none of the other benefits of FFI nor extensions even matter. Full stop.

Extensions, which are already implemented in lower-level languages like C or C++, would still need to be compiled to WebAssembly if the goal were full compatibility. This might lead us down the path of either creating a domain-specific language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to the library authors to choose lower-level languages (as is currently the case).

In essence, WebAssembly is great for certain scenarios, but PHP has existing mechanisms that make the addition of a Wasm runtime potentially redundant for most use cases.

Partial redundancy is not redundancy.

WASM's ability to run on a managed server – assuming it were built-in to PHP core — is the critical non-redundant benefit. If you cannot run those "existing mechanisms" then they fact they are redundant does not matter one iota.

-Mike

19

On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:

Yeah. That was the original goal.

But to say WASM's domain is limited to browsers is not valid any longer:
[...]

While it's definitely interesting seeing what uses it's being put to beyond the browser, the majority of those articles are talking about using WASM on its own, in the kind of places where you might use a container, to host things like microservices, serverless functions, etc.

Embedding it into other languages is a different usage again. It's certainly something that is being explored, e.g. by Extism, and that seems like a good project for anyone interested here to participate in, e.g. to help design the "glue" between PHP and WASM / Extism.

WASM's ability to run on a managed server – assuming it were built-in
to PHP core

Just to reiterate, if by "built-in to PHP core", you mean "every copy of PHP includes a functional WASM runtime", that's not going to happen. It would mean bundling (or requiring every user to install) a huge third-party dependency, with all of its dependencies and platform requirements, even if they weren't interested in using it.

The only runtimes where WASM is ever going to be available "out of the box" are those already built on a JavaScript engine (usually V8), like node.js, Deno, Electron, etc. The WASM is then running inside the existing runtime, not a whole new VM - like running Scala and Java code in the same JVM; or Hack and PHP in (older versions of) HHVM.

Regards,
--
Rowan Tommins
[IMSoP]

20

On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel <mike@newclarity.net> wrote:

On Sep 18, 2024, at 3:09 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
Yes and no. The primary goal of WebAssembly is to support high-performance applications on web pages. The premise is simple: JavaScript is the only language natively supported by browsers, but developers want to use various other languages (e.g., C, C++, Rust), particularly for performance-critical tasks. WebAssembly allows code written in these languages to be compiled to a universal format (Wasm) that browsers can run efficiently.

Yeah. That was the original goal.

That is the primary goal.

But to say WASM’s domain is limited to browsers is not valid any longer:

I don’t know where you got that since I never said anything along those lines. All I did was try to explain to you why browsers need wasm and why it makes sense for them to invest in implementing it.
But since you have all those guides and it’s so practical, what’s stopping you? You’d do a better job of convincing me with a MVP than some random blog posts. This is what we use for chrome/v8: https://github.com/WebAssembly/wasm-c-api/, have fun.

And even:

You mean the feature that’s been in beta since 2022? Yeah that’s exactly what I’m referring to. If docker and all their money and engineers haven’t shipped wasm in 2 years, how long do you think it’ll take a bunch of volunteers?

However, in the case of PHP, many of the benefits that WebAssembly brings to other languages are already available through PHP extensions or FFI for non-performance-sensitive tasks. Integrating a Wasm runtime into PHP would be a complex undertaking with significant risks, but it wouldn’t necessarily provide proportionate rewards, which is the main point I’m trying to make.

Many of the benefits, but NOT the most important one for a large number of installations.

The benefit that neither FFI nor extensions can touch is the ability to be run on a managed server. Without that, none of the other benefits of FFI nor extensions even matter. Full stop.

You can’t do shit on a managed server, that is not the bar at all. What makes you so sure that wasm will be allowed on managed hosts? What’s the incentive for providers to allow it?

Extensions, which are already implemented in lower-level languages like C or C++, would still need to be compiled to WebAssembly if the goal were full compatibility. This might lead us down the path of either creating a domain-specific language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to the library authors to choose lower-level languages (as is currently the case).

In essence, WebAssembly is great for certain scenarios, but PHP has existing mechanisms that make the addition of a Wasm runtime potentially redundant for most use cases.

Partial redundancy is not redundancy.

WASM’s ability to run on a managed server – assuming it were built-in to PHP core — is the critical non-redundant benefit. If you cannot run those “existing mechanisms” then they fact they are redundant does not matter one iota.

I hear you, you want to run low level code on managed servers. I would approach the problem differently e.g. Creating some kind of directory for trusted php extensions, the criteria for what qualifies as trusted would be up for discussion. Or maybe we can bundle a small std lib of select extensions with core. Those make a lot more sense to me than adding an entire abstraction layer.

Cheers.
Hammed.