Zephir, and other tangents

1 month ago by Mike Schinkel — view source

unread

Hi Rowan,

This message is in reply to https://externals.io/message/125455#125496 from the thread "bikeshed: Typed Aliases"

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 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

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] https://externals.io/message/125279
[2] https://en.wikipedia.org/wiki/WebAssembly
[3] https://webassembly.org/

1 month ago by Rowan Tommins [IMSoP] — view source

unread

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]

1 month ago by Mike Schinkel — view source

unread

Hi Rowan,

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/

1 month ago by Hammed Ajao — view source

unread

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:

&lt;?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.

1 month ago by Christoph M. Becker — view source

unread

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

Christoph

1 month ago by Mike Schinkel — view source

unread

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

1 month ago by Adam Zielinski — view source

unread

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!) https://github.com/jasperweyne/unwasm
WebAssembly runtime as a PHP language extension:
https://github.com/veewee/ext-wasm
WebAssembly runtime as a PHP language extension:
https://github.com/extism/php-sdk

[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

1 month ago by Mike Schinkel — view source

unread

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!) https://github.com/jasperweyne/unwasm https://github.com/jasperweyne/unwasm

WebAssembly runtime as a PHP language extension: https://github.com/veewee/ext-wasm https://github.com/veewee/ext-wasm

WebAssembly runtime as a PHP language extension: https://github.com/extism/php-sdk https://github.com/extism/php-sdk

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

Want to work on an RFC?

-Mike

1 month ago by Adam Zielinski — view source

unread

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!) https://github.com/jasperweyne/unwasm

WebAssembly runtime as a PHP language extension: https://github.com/veewee/ext-wasm

WebAssembly runtime as a PHP language extension: https://github.com/extism/php-sdk

[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

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] https://github.com/extism/php-sdk
[4] https://www.youtube.com/watch?v=ChZpveTipPU&themeRefresh=1 (I
think it was that one)

1 month ago by Rob Landers — view source

unread

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!) https://github.com/jasperweyne/unwasm

WebAssembly runtime as a PHP language extension: https://github.com/veewee/ext-wasm

WebAssembly runtime as a PHP language extension: https://github.com/extism/php-sdk

[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

1 month ago by Dennis Snell — view source

unread

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!) https://github.com/jasperweyne/unwasm

WebAssembly runtime as a PHP language extension: https://github.com/veewee/ext-wasm

WebAssembly runtime as a PHP language extension: https://github.com/extism/php-sdk

[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

1 month ago by Hammed Ajao — view source

unread

On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell dennis.snell@automattic.com
wrote:

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!)
https://github.com/jasperweyne/unwasm

WebAssembly runtime as a PHP language extension:
https://github.com/veewee/ext-wasm

WebAssembly runtime as a PHP language extension:
https://github.com/extism/php-sdk

[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.

I'm not convinced. That's what they said about nodejs(same algos and same
language on FE and BE). Except it's not really that consistent because
there are several discrepancies between the browser and node runtime. I'll
believe it when I see it.

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.

I can see the appeal of that though.

The other major area is similar, and we’ve seen this with the HTML and XML
parsing work recently undertaken in WordPress.

Yeah you could talk about html parsing before 8.4 but with 8.4 we get
lexbor (thanks to niels) and that's as good as it gets. Php already has
beautiful support for XML though so I'm not sure why you would implement a
parser yourself.

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.

What exactly do you mean by jump into wasm? Like hand write it? Or you mean
jump into a language that can be compiled to wasm? How about debugging at
runtime? And if you mean better performance than PHP, while that is likely,
it isn't guaranteed. PHP is pretty fast and will be faster for some
routines that are optimized by the engine. Wasm will never be as fast as
extensions though because with extensions, all you're doing is extending
the engine. Same as any internal extension. With wasm you're interoperating
with an entirely separate VM.

Additionally, it’s a perk being able to write such algorithms in languages

that aid that development through more powerful type systems.

We can agree on that. But I use C++ for my extensions so there's also that.

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.

Imo this is where FFI should shine but I'll admit that the current
implementation is lacking in both security and functionality.

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.

Shared hosting for php gets you the worst possible version of php. Can't
recompile to enable any bundled extension, can't install any new
extensions, so how exactly would you approach this? Wasm bundled with the
engine by default? Or some kind of opt in mechanism that shared hosters
won't even be able to use?

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

I actually love wasm, I'm currently in the process of compiling my mini php
runtime to wasm (basically a browser only version of 3v4l). I'm not against
this for any personal reasons, I'm simply not sure it's the right approach.

Cheers,
Hammed

1 month ago by Dennis Snell — view source

unread

Hi Hammed, thank you for taking the time to read through this and share your thoughts.

On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell <dennis.snell@automattic.com

wrote:

To summarize, I think PHP would benefit from:

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,

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:

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?

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 (!) https://github.com/jasperweyne/unwasm

WebAssembly runtime as a PHP language extension: https://github.com/veewee/ext-wasm

WebAssembly runtime as a PHP language extension: https://github.com/extism/php-sdk

[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.

I'm not convinced. That's what they said about nodejs(same algos and same language on FE and BE). Except it's not really that consistent because there are several discrepancies between the browser and node runtime. I'll believe it when I see it.

There’s a note about this point that I think is worth calling out, and that is something you probably already know, but JavaScript runtimes provide a standard library while a WASM runtime is mostly just a virtual machine. There’s also nothing provided that I’m aware of in WASM that offers filesystem access or network access, which are major areas where in-browser JavaScript and NodeJS backends differ (because the browser and server environments are fundamentally limited by different needs).

As things stand, projects are compiled into WebAssembly and literally run identically in the different runtimes because it’s the bytecode that’s specified, not specific functions or libraries. Whereas with JavaScript we’re shipping source code and interacting with very different systems, WASM bundles are a few steps removed from that, and have no DOM or system access to interact with.

I’m fairly confident we can say that it’s non-controversial that folks routinely run identical algorithms across different WASM runtimes in different environments. As you mentioned elsewhere, it’s very much akin to how Java and Closure and Scala all run on the JVM just fine together even being different languages, except in this case the runtime is an isolated sandbox by default with no external system access. WASM is a lovely little VM, successful in ways many before it haven’t been.

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.

I can see the appeal of that though.

The other major area is similar, and we’ve seen this with the HTML and XML parsing work recently undertaken in WordPress.

Yeah you could talk about html parsing before 8.4 but with 8.4 we get lexbor (thanks to niels) and that's as good as it gets. Php already has beautiful support for XML though so I'm not sure why you would implement a parser yourself.

It’s wonderful that PHP is finally getting a spec-compliant HTML DOM parser for the first time in its history, but \Dom\HTMLDocument is not the right interface for every server need, and remains ill-suited for the kind of work typical in a WordPress site, which needs to run on low memory budgets, perform as fast as possible, and exceed the safety of what a generic DOM parser produces (there are cases that \Dom\HTMLDocument will still introduce vulnerabilities into an HTML document because it’s able to create DOM trees that cannot be represented by HTML upon serialization, and as it implements the HTML spec, it cannot prevent creating those trees). There are still a number of steps every developer needs to take to properly setup the parser and get the right results back, and the parser has to load the entire DOM tree into memory before any reads or manipulations can be performed on it.

WordPress’ HTML API is a near-zero memory overhead streaming HTML parser designed around safe-by-default reading and writing of HTML which requires no configuration or manual steps to get “the right thing.” It’s also significantly slower in user-space PHP than it needs to be. I hope one day that PHP has its own copy of this streaming parser design, which is performant and available in every copy of PHP (which is another issue with code only available in extensions), but even if that never happens, running C or Rust code compiled to WebAssembly would provide almost the same value as having that design implemented in the language.

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.

What exactly do you mean by jump into wasm? Like hand write it? Or you mean jump into a language that can be compiled to wasm? How about debugging at runtime? And if you mean better performance than PHP, while that is likely, it isn't guaranteed. PHP is pretty fast and will be faster for some routines that are optimized by the engine. Wasm will never be as fast as extensions though because with extensions, all you're doing is extending the engine. Same as any internal extension. With wasm you're interoperating with an entirely separate VM.

By jumping into WASM I’m talking about the second thing you mention: calling functions written in languages compiled to WebAssembly. Even with the overhead of marshaling data, the things that WebAssembly is good at are the things that PHP is slow at: specifically things like raw numeric computation and string manipulation and parsing. I write a lot of parsing code and frequently am surprised at the overhead cost of string processing and array operations in PHP. There are a number of straightforward operations available in C that just can’t be done in PHP. I don’t see this as a failing of PHP, just an aspect of how it is.

For runtime debugging I don’t have any particular thoughts. I’m not aware of anyone who has ever tried to runtime debug CURL calls or things like mb_convert_encoding(). Functions invoked in the WASM runtime would more or less be library functions, like ffmpeg. Debugging would likely most frequently be done as a library and dumped into the PHP application with no expectation for debugging.

Effectively these are user-space PHP extensions, and are very convenient because they can be updated without recompiling PHP or begging web hosts to update their PHP version, or to do that every other Tuesday, or whenever another security exploit is fixed in some image processor. On that note, the ability to sandbox image processing code (and any other user-provided content) is a huge perk. Many of the exploits of past PHP extensions could be contained inside the VM, which has limited ability to reach out into the system. Fixing vulnerabilities and bugs becomes something any auto-updater can accomplish, requiring no effort or interaction on the part of the host.

Additionally, it’s a perk being able to write such algorithms in languages that aid that development through more powerful type systems.

We can agree on that. But I use C++ for my extensions so there's also that.

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.

Imo this is where FFI should shine but I'll admit that the current implementation is lacking in both security and functionality.

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.

Shared hosting for php gets you the worst possible version of php.

Couldn’t have said it better myself!

Can't recompile to enable any bundled extension, can't install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won't even be able to use?

As with many of the things I’ve been writing on this list lately, to me, an embedded WASM runtime makes most sense as a central language feature and available everywhere PHP is deployed. There are a few core basic subsystems that either are foundational to the environment PHP operates in (for example, web-related technologies like HTTP and HTML and URLs) or which bring so much value to the language that it opens up brand new paradigms or potentially removes major maintenance burdens.

If we could ship imagemagick as a WASM extension there would be no need for the imagemagick extension. The security environment out of the box is so much better; it’s not worth the lost potential for performance that a native extension offers. Someone may not agree with this, and that’s fine because they can always install a native extension or utilize the FFI on infrastructure they control.

I think at times WordPress sees a very different picture of the world than many great PHP projects see. Our reality is that we’re writing code that runs on hardware we don’t control or even know about. We cannot in any way install or force certain extensions to be present. The worst possible version of PHP is literally the constraint at which we are allowed to code. Anything beyond that and we can’t ship it because a large fraction of the internet will start crashing. It’s frustrating, but also an honor to be able to ensure that people who can’t afford high end servers can still build their own place on the world wide web.

Over the past several years, though, WordPress has also been a positive influence on persuading hosts to update their PHP versions, because PHP has gotten better enough that the argument is easy: upgrade to PHP 7 and your data center costs will drop X%. It’s not too hard to imagine winning similarly on the security argument.

WASM code on memory-constrained, oversubscribed, CPU-poor hosts is still considerably better for certain kinds of computation than user-space PHP code on memory-constrained, oversubscribed, CPU-poor 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

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

Warmly,
Dennis Snell

I actually love wasm, I'm currently in the process of compiling my mini php runtime to wasm (basically a browser only version of 3v4l). I'm not against this for any personal reasons, I'm simply not sure it's the right approach.

That sounds awesome. The WordPress Playground ships a copy of PHP compiled to WASM, and it’s been an incredible journey realizing just what’s capable with this technology. It’s really boosted the developer experience working on WordPress itself and also that of those building their own projects using WordPress. Some are already bringing in libraries like ffmpeg to convert images and media on the frontend, though it’s sad that can’t also be done on the server yet.

Cheers,
Hammed

Hope you have a nice weekend. Cheers.

1 month ago by Arvids Godjuks — view source

unread

On Fri, 20 Sept 2024 at 09:17, Dennis Snell dennis.snell@automattic.com
wrote:

Hi Hammed, thank you for taking the time to read through this and share
your thoughts.

snip

Cheers,
Hammed

Hope you have a nice weekend. Cheers.

Hello everyone,

I want to chip in here, since reading the thread lead me into a state of
cognitive dissonance.
I've been in PHP world for a long time, about 3 years shy of how old
Wordpress is. When I'm reading "shared hosting" and "WASM" and knowing how
managed hosting works, I have to ask: What type of la-la land is this
conversation is taking place in?
All managed wordpess hosting is locked down hard. Extensions are very
limited and everything that allows any type of freedom is disabled,
functions are disabled en mass. I have to ask: knowing the history of past
27 years, what managed hoster in their right mind and sanity will allow
WASM to be enabled to bypass ____A L L _____ PHP security features and
allow PHP code do anything it wants? On a shared hosting... I seriously
want to know answer to this question, because I firmly believe there was
zero risk and security assessment not only done, but it hasn't been even a
twinkle in the eye.

On VPS/Decicated you can run whatever you want, so you don't have the
limitations.

On other note - people have pointed out how big body of work it is. If you
want to sponsor WASM development for PHP, I suggest Automatic open their
wallet and put in 2-3 million $ a year for the next 5-10 years to
PHPFoundation and find devs who are capable and willing to do this job.
Honestly, I think you might find people to want to do that rather than lack
of money being the cause of it.

Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

1 month ago by Dennis Snell — view source

unread

On Fri, 20 Sept 2024 at 09:17, Dennis Snell <dennis.snell@automattic.com

wrote:

Hi Hammed, thank you for taking the time to read through this and share your thoughts.

snip

Cheers,
Hammed

Hope you have a nice weekend. Cheers.

Hello everyone,

I want to chip in here, since reading the thread lead me into a state of cognitive dissonance.

Hi Arvīds, that sounds stressful. This is definitely a wavering thread, as noted by the “tangents” subject. As far as the email you’re replying to, the main point is that if PHP offered a way to embed safe native-like extensions in a sandbox, then lots of the pressure to add and maintain extensions would drop from the host and provider and enable the customers to manage that on their own, and open many doors for PHP. A WASM runtime engine inside PHP would be a viable path to get to that point.

I've been in PHP world for a long time, about 3 years shy of how old Wordpress is. When I'm reading "shared hosting" and "WASM" and knowing how managed hosting works, I have to ask: What type of la-la land is this conversation is taking place in?
All managed wordpess hosting is locked down hard. Extensions are very limited and everything that allows any type of freedom is disabled, functions are disabled en mass. I have to ask: knowing the history of past 27 years, what managed hoster in their right mind and sanity will allow WASM to be enabled to bypass ____A L L _____ PHP security features and allow PHP code do anything it wants? On a shared hosting... I seriously want to know answer to this question, because I firmly believe there was zero risk and security assessment not only done, but it hasn't been even a twinkle in the eye.

These are good questions. The basic point of confusion might stem from what the security domain is for a WASM runtime. It’s actually precisely because of the concerns you raise that WASM is a candidate here, being sandboxed by default and unable to interact with the host system.

That is, a WASM extension not only can’t bypass any PHP security features, but it’s significantly more constrained than any PHP code is. Managed hosts are locked down largely because of the security concerns that are categorically not present with the system we’re discussing, so being able to offer more on their platforms without having to dedicate additional resources to it could be a nice selling point.

On VPS/Decicated you can run whatever you want, so you don't have the limitations.

I mentioned this in my email; I appreciate that many folks around here have full control over their infrastructure, but when building platform like WordPress or any of the other PHP frameworks, we just don’t have the liberty of having that control. In any case, even some very large shops who write and manage their own PHP extensions are constantly on the hook for security issues and updates and breakages. I’m sure we’d do much more at Automattic to extend PHP if we could do so without the security, platform-dependancy, and build issues involved in maintaining custom extensions.

On other note - people have pointed out how big body of work it is. If you want to sponsor WASM development for PHP, I suggest Automatic open their wallet and put in 2-3 million $ a year for the next 5-10 years to PHPFoundation and find devs who are capable and willing to do this job. Honestly, I think you might find people to want to do that rather than lack of money being the cause of it.

I’m not sure why you’re singling out Automattic, since nobody from Automattic started this thread or requested other people provide unfunded volunteer work, or why you’re expecting a single corporate entity to fully fund long-term planned features in the language. Is that how PHP normally grows? I’m not familiar with the process.

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

--

Arvīds Godjuks+371 26 851 664
arvids.godjuks@gmail.com

Telegram: @psihius https://t.me/psihius

Warmly,
Dennis Snell

1 month ago by Larry Garfield — view source

unread

I’m not sure why you’re singling out Automattic, since nobody from
Automattic started this thread or requested other people provide
unfunded volunteer work, or why you’re expecting a single corporate
entity to fully fund long-term planned features in the language. Is
that how PHP normally grows? I’m not familiar with the process.

My goal in sharing here is to help better represent my own perspective
of WordPress’ needs based on what I’ve seen. It’s long been on my list
to propose a WASM RFC, but because I personally haven’t had the
priority available to get an implementation working I haven’t done so.
It’s my impression from the documentation that the purpose of these
email threads w.r.t. RFCs is to gather interest and input before any
RFC would be put together, to hold these discussions before anyone
commits any major time to it.

FWIW, I feel that an embedded Wasm bridge, with a good API, would be an excellent addition and way more useful than the crappy experience of FFI.

Logistical question, for those with more stdlib expertise: Since we have other extensions in php-src that only work if you install some other library as well (eg, curl), which distros pretty much take care of for us, would a small in-php-src extension that is just a thin wrapper for Wasmtime or similar be viable? Not embedding Wasmtime into the php-src code, just the extension, and it's up to the user/distro to install both so that they work.

(Note: I'm not asking if you think it's a good idea, just if it's physically possible/worth discussing.)

--Larry Garfield

1 month ago by Niels Dossche — view source

unread

FWIW, I feel that an embedded Wasm bridge, with a good API, would be an excellent addition and way more useful than the crappy experience of FFI.

:confused_face:

Logistical question, for those with more stdlib expertise: Since we have other extensions in php-src that only work if you install some other library as well (eg, curl), which distros pretty much take care of for us, would a small in-php-src extension that is just a thin wrapper for Wasmtime or similar be viable? Not embedding Wasmtime into the php-src code, just the extension, and it's up to the user/distro to install both so that they work.

Perhaps I'm missing something in this discussion, as this discussion has all sorts of tangents and is quite lengthy. Also easy to forget what's been said and not.
Anyway, there is already a wasm extension for PHP: https://github.com/veewee/ext-wasm

Kind regards
Niels

1 month ago by Rowan Tommins [IMSoP] — view source

unread

Logistical question, for those with more stdlib expertise: Since we have other extensions in php-src that only work if you install some other library as well (eg, curl), which distros pretty much take care of for us, would a small in-php-src extension that is just a thin wrapper for Wasmtime or similar be viable? Not embedding Wasmtime into the php-src code, just the extension, and it's up to the user/distro to install both so that they work.

This is basically what I was answering, to the best of my understanding, here https://externals.io/message/125499#125619 and here https://externals.io/message/125499#125638

It's absolutely possible to build a PHP extension that interfaces to a WASM runtime, and links have been shared to at least two projects doing just that. Adding that to the php-src repo doesn't change what that extension can do, it just marks it as "approved" in some slightly ill-defined way, and restricts it to having new releases only once per year.

I think there's an impression that somehow by proposing that "we" add some complex functionality "to the language", it will suddenly attract developers and become stable and universally adopted; but it's really the other way around: once there's a mature implementation, and some people offering to maintain it, we can consider moving it to the php-src repo, if that seems beneficial. (And if other constraints are met, such as licensing.)

At which point, some managed hosting servers might be more willing to install it. Not the ones who don't even install ext/curl, those are never going to benefit from this. But maybe the ones who install a reasonable list of features, but are a bit wary of installing PECL extensions they don't know much about, can be persuaded to trust their users with a WASM sandbox.

There have been a couple of mentions on this thread of writing an RFC, but I can't think of anything that an RFC could realistically propose right now. So I say again, to those of you interested in the topic: contribute to the projects already building the extensions, that's where the next steps are, not here.

Regards,
Rowan Tommins
[IMSoP]

1 month ago by Jakub Zelenka — view source

unread

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell dennis.snell@automattic.com
wrote:

My goal in sharing here is to help better represent my own perspective of
WordPress’ needs based on what I’ve seen. It’s long been on my list to
propose a WASM RFC, but because I personally haven’t had the priority
available to get an implementation working I haven’t done so. It’s my
impression from the documentation that the purpose of these email threads
w.r.t. RFCs is to gather interest and input before any RFC would be put
together, to hold these discussions before anyone commits any major time to
it.

Is your objective to support building PHP to wasm32-wasi target like it was
proposed here: https://github.com/php/php-src/pull/10457 ? If so, the main
issue with that was inability to do the zend_bailout as wasm does not
support currently support setjmp and longjmp. Otherwise it's mostly about
disabling some functionality.

Regards

Jakub

1 month ago by Dennis Snell — view source

unread

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell <dennis.snell@automattic.com

wrote:

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

Is your objective to support building PHP to wasm32-wasi target like it was proposed here: https://github.com/php/php-src/pull/10457
? If so, the main issue with that was inability to do the zend_bailout as wasm does not support currently support setjmp and longjmp. Otherwise it's mostly about disabling some functionality.

It’s the other way around. We’ve been having a great time already building PHP as a WASM binary - we package it with SQLite and WordPress to create “The WordPress Playground.” There’s a wonderful new world of things that can happen when packaging PHP inside a WASM runtime.

However, this is about calling compiled WebAssembly code from user-space PHP.

load_wasm( DIR . ‘/interesting-computation.wasm’ );
$description = null;
call_wasm_func( ‘lazy_json_decode’, $json, ‘items[0].description’, $description );

This is about things including, but not limited to the following scenarios:
- Properly parsing HTML, JSON, XML, URLs, image formats, and more, but don’t want the
severe text-processing penalty from user-space PHP code.

- Ensuring that efficient tools are available to PHP code even when hosts don’t allow installing extensions,
even when the site owners have no idea what an extension is or how to install one.

- Updating libraries that convert or resize images when bug fixes are made, without having to demand
that hosts accept that responsibility and burden themselves.

- Share algorithms between JavaScript on the frontend and PHP on the backend, particularly those dealing
with string processing (for example, slug generation, sanitization, decoding).

- Explore novel software ideas and get them out to testing and iteration without having to ask the entire
ecosystem to adopt them as extensions.

Regards

Jakub

Same! Cheers.
Dennis Snell

1 month ago by Jakub Zelenka — view source

unread

Hi,

On Fri, Sep 20, 2024 at 9:36 PM Dennis Snell dennis.snell@automattic.com
wrote:

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell dennis.snell@automattic.com
wrote:

My goal in sharing here is to help better represent my own perspective of
WordPress’ needs based on what I’ve seen. It’s long been on my list to
propose a WASM RFC, but because I personally haven’t had the priority
available to get an implementation working I haven’t done so. It’s my
impression from the documentation that the purpose of these email threads
w.r.t. RFCs is to gather interest and input before any RFC would be put
together, to hold these discussions before anyone commits any major time to
it.

Is your objective to support building PHP to wasm32-wasi target like it
was proposed here: https://github.com/php/php-src/pull/10457? If so, the
main issue with that was inability to do the zend_bailout as wasm does not
support currently support setjmp and longjmp. Otherwise it's mostly about
disabling some functionality.

It’s the other way around. We’ve been having a great time already building
PHP as a WASM binary -

Ah ok I just did a bit of research and checking your wordpress-playground
and it uses emscripten which actually integrates extensions to WASM
(currentl proposed https://github.com/WebAssembly/exception-handling ) or
it can JavaScript based support as described in
https://emscripten.org/docs/porting/setjmp-longjmp.html . So it's not
actually an issue in your case. Officially PHP can still cannot be build to
the official wasm32-wasi target but as I understand it's not such a big
issue because there are already viable alternatives.

Cheers

Jakub

1 month ago by Pierre Joye — view source

unread

On Sat, Sep 21, 2024, 3:41 AM Dennis Snell dennis.snell@automattic.com
wrote:

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell dennis.snell@automattic.com
wrote:

My goal in sharing here is to help better represent my own perspective of
WordPress’ needs based on what I’ve seen. It’s long been on my list to
propose a WASM RFC, but because I personally haven’t had the priority
available to get an implementation working I haven’t done so. It’s my
impression from the documentation that the purpose of these email threads
w.r.t. RFCs is to gather interest and input before any RFC would be put
together, to hold these discussions before anyone commits any major time to
it.

Is your objective to support building PHP to wasm32-wasi target like it
was proposed here: https://github.com/php/php-src/pull/10457? If so, the
main issue with that was inability to do the zend_bailout as wasm does not
support currently support setjmp and longjmp. Otherwise it's mostly about
disabling some functionality.

It’s the other way around. We’ve been having a great time already building
PHP as a WASM binary - we package it with SQLite and WordPress to create
“The WordPress Playground.” There’s a wonderful new world of things that
can happen when packaging PHP inside a WASM runtime.

However, this is about calling compiled WebAssembly code from user-space
PHP.
load_wasm( __DIR__ . ‘/interesting-computation.wasm’ );
$description = null;
call_wasm_func( ‘lazy_json_decode’, $json, ‘items[0].description’,
$description );

this is a very important target which is not directly discussed in this
thread.

I played with the (very good) IR when it was submitted by Dmitry back then.
It sounded like the most effective way.

However it was not designed (nothing bad with that) with such goals in
mind. I was hoping it could be used like any other IR (similar to what llvm
does f.e.) to then target wasm. The closest one from php is python with
py2wasm, but there are pretty existing solutions that make it possible,
they use the out of python core approach:

https://wasmer.io/posts/py2wasm-a-python-to-wasm-compiler

which looks very much like what could be done with php as I see the chances
to have that in php as very low without major changes.

best,
Pierre

It may be possible but the time required to figure it out is not something
I have sadly (falling back to porting our php code to other when we need it
to be used in many environments where putting a php is not an option).

As of now, I feel like writing a parser-compiler may be easier, even with
limited features. But ideally the way could be to allow it the same way we
can see it in other languages, but the paradigms used are very different.

All in all, it is not absolutely vital for php to have this but it will
help to keep it on for the next 2 decades. Similarly to other discussions
lately about new types.

best,
Pierre

29 days ago by Mike Schinkel — view source

unread

I want to chip in here, since reading the thread lead me into a state of cognitive dissonance.
I've been in PHP world for a long time, about 3 years shy of how old Wordpress is. When I'm reading "shared hosting" and "WASM" and knowing how managed hosting works, I have to ask: What type of la-la land is this conversation is taking place in?

See these lists above showing the required and recommended extensions for WordPress, Laravel and Drupal where all(?) other CMS/frameworks have an equivalent list:

Managed hosts that want to sell to users of a CMS or frameworks operate in the "la-la land" you speak of.

what managed hoster in their right mind and sanity will allow WASM to be enabled to bypass ____A L L _____ PHP security features and allow PHP code do anything it wants?

That is a false assertion. WASM cannot bypass all PHP security; it is by-nature sandboxed.

Yes, there are ways that a good C++ developer could get around that, but as part of this discussion we have been discussing ways to avoid allowing that, such as potentially enabling WASM for PHP to only allow using AssemblyScript, at least initially.

On a shared hosting... I seriously want to know answer to this question, because I firmly believe there was zero risk and security assessment not only done, but it hasn't been even a twinkle in the eye.

On VPS/Decicated you can run whatever you want, so you don't have the limitations.

Shared hosting vs. VPS/Dedicated is a false dichotomy.

There is also managed hosting – typically run in sandboxed containers — that specialize in running specific CMS and/or frameworks.

On other note - people have pointed out how big body of work it is. If you want to sponsor WASM development for PHP, I suggest Automatic open their wallet and put in 2-3 million $ a year for the next 5-10 years to PHPFoundation and find devs who are capable and willing to do this job. Honestly, I think you might find people to want to do that rather than lack of money being the cause of it.

Well, that is an option, and I would be glad to see it.

However, my guess is that Automattic (spelled correctly) is not likely to do that given how dismissive PHP Internals and by extension the PHP Foundation has been regarding the needs of WordPress users for as long as you Arvids have been doing PHP.

But who knows, maybe there could be a détente? Who on this list would be more open than in the past to treat concerns of WordPress users as legitimate rather than dismiss them because (I am paraphrasing) "how bad their code is?"

Perhaps I'm missing something in this discussion, as this discussion has all sorts of tangents and is quite lengthy. Also easy to forget what's been said and not.
Anyway, there is already a wasm extension for PHP: https://github.com/veewee/ext-wasm

The something you might be missing is the discussion is about potentially having WASM as a bundled extension in PHP core rather than there just having one be available, and the reason is so that it can become a viable option for CMS & Framework vendors to include on their list of required or at least recommended extensions.

It's absolutely possible to build a PHP extension that interfaces to a WASM runtime, and links have been shared to at least two projects doing just that. Adding that to the php-src repo doesn't change what that extension can do, it just marks it as "approved" in some slightly ill-defined way, and restricts it to having new releases only once per year.

I think there's an impression that somehow by proposing that "we" add some complex functionality "to the language", it will suddenly attract developers and become stable and universally adopted; but it's really the other way around: once there's a mature implementation, and some people offering to maintain it, we can consider moving it to the php-src repo, if that seems beneficial. (And if other constraints are met, such as licensing.)

No, it is not "the other way around," it is both, and mischaracterizing it to say that the only way hosting providers will install something is if it becomes popular dismisses the valid approach we've been advocating for, or at least for installations on a reasonably widespread basis (~1/3rd of hosts or more)

What your dismissal ignores is that many hosts won't install something unless a Framework or CMS requires or at least recommends it. And no Framework or CMS that cares anything at all about risk management — e.g. none with a large userbase — would require or at least recommend an extension that is not bundled with PHP unless there is overwhelming need for it and it targets a business vs. a technical need.

I absolutely love that Larry called the question if it were technically possible. Maybe Larry will read this and can answer the question — since he was heavily involved with Drupal — "Would Drupal be willing to require or at least recommend a 3rd party WASM extension vs. a bundled one here? https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions"

At which point, some managed hosting servers might be more willing to install it. Not the ones who don't even install ext/curl, those are never going to benefit from this.

There are very few (if any) that won't install curl as you cannot run WordPress w/o curl. Your knowledge of what hosting providers will and will not install seems to be rather dated.

But maybe the ones who install a reasonable list of features, but are a bit wary of installing PECL extensions they don't know much about, can be persuaded to trust their users with a WASM sandbox.

Or the ones who want to target the users of the CMS or Framework that recommend or require the extension.

If the extension were bundled then I expect it could become a recommended extension for hosts to enable and WordPress could start shipping WASM extensions for the use-cases Dennis Snell mentioned that can optionally run if the WASM extension is enabled vs. if not it would just run the old slower PHP code.

BTW, Dennis, could you see WordPress recommending a WASM extension if PHP bundled one here? https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions

Ah so you want to make huge changes to the engine for even less users?

Why make such a leading yet false assertion?

The fact it can be implemented in an PHP extension discretions your assert that it would require "huge changes to the engine." In fact, it would not require any changes to the engine.

If you insist, I'll await your MVP.

Here it is: https://github.com/wasmerio/wasmer-php/releases/tag/1.1.0

So maybe those companies should implement it themselves or pay to have it implemented.

Or maybe those companies just give up on using PHP rather than constantly deal with intransigence among community members when improvements are even mentioned? Most of my work has been in Go lately, motivated in large part because of PHP's governance model that centers around this list and the hostile and non-constructive reactions that are far too common on this list.

How would we handle the JS-like stdlib of assembly script? Another abstraction layer? That seems easier to you than a DSL created specifically for this?

You mischaracterize, but yes, an existing working WASM is easier IMO than a DSL that is just "concepts of a plan."

(Those quotes were not yours, I am just making a pun on something that was said recently by someone well-known in the USA.)

With PHP like syntax?

Why is "PHP like syntax" a blocking requirement? C does not have a PHP-like syntax, or at least one that is not more similar to AssemblyScript than PHP. Why then is C acceptable for extensions but AssemblyScript is not?

And even so, there is no reason a PHP-like syntax is required. PHP developers work with JS or TS every day, and AssemblyScript is just a variant of TypeScript.

Using the parser already in the engine? With a PHP-like stdlib?

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.

Then for those cases where it is redundant, don't use it.

That's most use cases. It doesn't make any sense to burden all users and contributors just so some companies can maybe decide to enable wasm to make more money.

First, it would not burden all users nor all contributors; that is an invalid claim I have discredited above.

Second, that sounded like a Freudian slip where you said the quiet part out loud. Is this about you somehow having a hot button about "some people wanting to make money" rather than accepting people just want to be able to write better and faster websites in PHP? If "some people wanting to make money" were the discrediting bar then (almost?) every feature request could be denied on that basis.

Honestly, a DSL would be the perfect solution here. Anyone familiar with writing PHP extensions knows about gen_stub.php, which scans PHP stubs and generates the corresponding binding C code.

When and where does the C code get compiled?

And isn't that what Zephir actually is?

I've often thought this process could be extended to handle more complex scenarios like promoted properties, simple expressions (e.g., assignments, property access, comparisons), and anything that can be easily translated into C code.

V8 has a similar tool called Torque, and I've always wondered what something like that would look like for PHP. It would result in a strict, statically typed subset of PHP that satisfies all the requirements, except for the last one (which it would only partially fulfill).

Since the generated code would interface directly with the Zend API, we can consider the DSL code as safe as the PHP implementation itself. While there wouldn't be CPU throttling, hosts shouldn't have major objections since it would essentially be as safe as PHP.

Most importantly, this approach would benefit everyone. It would have no third-party dependencies and would only need to evolve alongside PHP/Zend as they grow.

That’s how I would approach it.

I await your proposal. Sincerely.

And I don't mean to the level of an RFC, but a document that details how it would work, and one that could be discussed and commented on as you can on a Github repo.

Note I am not advocating fro a specific approach — e.g. WASM — I am advocated to achieved the stated goal, e.g. an extension mechanism that can run at near native speed for low-level string parsing and maths that realistically will be able to be run on managed hosts which IMO means they have to be adopted by major CMS and/or Frameworks as requirements if not at least recommendations.

If your ideas can achieve those goals, I would fully be behind them. (I am however skeptical that what you proposal can achieve all those goals; prove me wrong.)

Moot point as it cannot be run on a managed hosted server.

Why not? Only because the people managing that server haven't been persuaded to include it as an option. And that is mostly because it's currently experimental, and there isn't wide demand for it.

You can hypothetical all day long, but the reality is that if something is not shipped with PHP, someone wanting to write PHP code that a library, CMS or frameworks depends on would have to play a failure-guaranteed game of whack-a-mole to get a lot of managed hosting providers to support it.

And the larger CMS and frameworks are rightly not going to support something that does not get bundled into php-src.

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.

So why do you claim that bundling a third-party dependency is a "never going to happen" scenario?

By that logic PHP would have none of these functionalities:

• cURL
• GD
• PDO
• OpenSSL
• MBString
• Zlib
• Zip
• XSL
• EXIF
• BCMath

None of those are "built into PHP core" in the sense of "every copy of PHP includes them". Nor do any of them bundle their third-party dependencies.They are all optional extensions, which the user has to provide the dependencies for if they want to install and enable them.

Fine, we can treat WASM the same as all those other extensions and bundling it with PHP meaning ;extension=wasm line in production.ini, the internal code needed to link in the library, and compiler switches to compile it in.

If PHP were to ship in this way then CMS and Frameworks could choose to add WASM to their list of required or recommended extensions, as it sounds like from Dennis Snell's really excellent messages that WordPress would likely want to do that:

Once CMS & Frameworks are empowered to use WASM as part of their core offering then they could start recommending WASM and managed web hosts that want to cater to their users would start offering WASM enabled on their platforms.

BTW, very few CMS or Frameworks make any extensions not referenced in production.ini as requirements, and for very good reason because doing so would be too risky.

They are what is sometimes referred to as "bundled extensions", which just means they have source code in the php-src repository, and get new releases at the same time as PHP. Being in that list doesn't mean managed hosts have to provide them (who would force them?) and not being in that list doesn't mean managed hosts can't provide them (it's as easy to install "php-mongodb" on Ubuntu as "php-mysqli", even though one is "bundled" and the other hosted on PECL).

Being "bundled" may be interpreted as something of a "stamp of approval", indicating that an extension is mainstream and stable. That's something that has to be earned - many extensions started out in their own projects, with releases listed on PECL or elsewhere, and were proposed for adoption into the php-src repo once they became stable.

Which is why I say your energies for now are best spent on a project like extism, or wasmer-php - build that stable extension, and then we can discuss whether it would be beneficial to adopt it into the php-src repo.

Then let us redirect our discussion as to whether it would be beneficial to adopt wasmer-php into php-src repo, an objective list of reasons it would not, if not, and an objective list of things it could do to resolve those objections.

That would be much more productive than debating hypotheticals.

-Mike

29 days ago by Christoph M. Becker — view source

unread

However, my guess is that Automattic (spelled correctly) is not likely
to do that given how dismissive PHP Internals and by extension the PHP
Foundation has been regarding the needs of WordPress users for as long
as you Arvids have been doing PHP.

But who knows, maybe there could be a détente? Who on this list would
be more open than in the past to treat concerns of WordPress users as
legitimate rather than dismiss them because (I am paraphrasing) "how bad
their code is?"

It would be ridiculous to dismiss any software written in PHP for having
bad code, given the relatively huge amount of really bad PHP code we
still have (e.g. web-pecl). And I hope that we are not (and have not
been) generally dismissive of any PHP project whatsoever.

However, we cannot please everybody. Bundling an extension increases
the maintenance burden for the relatively few php-src developers; making
an extension mandatory, or integrating something into the core, even
more so, since we may need to also bundle and maintain external
libraries (see e.g. ext/pcre). This doesn't mean that it can't happen,
but obviously this requires the RFC process.

Regarding https://github.com/wasmerio/wasmer-php which has mentioned a
couple of times in this thread, I'm afraid the project has been
abandoned. See e.g.
https://github.com/wasmerio/wasmer-php/issues/147. But maybe someone
replies to https://github.com/wasmerio/wasmer-php/issues/151. :)

Christoph

29 days ago by Adam Zielinski — view source

unread

On Mon, Sep 23, 2024 at 8:14=E2=80=AFAM Mike Schinkel mike@newclarity.net=
wrote:

At which point, some managed hosting servers might be more willing to i=
nstall it. Not the ones who don't even install ext/curl, those are never go=
ing to benefit from this.
There are very few (if any) that won't install curl as you cannot run Wor=
dPress w/o curl. Your knowledge of what hosting providers will and will no=
t install seems to be rather dated.

Just to add to that: without curl, WordPress falls back to a limited
fsockopen-based network transport. Sometimes that's problematic, so
I'm incubating a dependency-free HTTP client that can do streaming,
async connections etc. using only functions shipped in core PHP [1].
I'll eventually propose it for WordPress core as either a better
fallback or as a replacement for curl. If PHP had WASM support,
WordPress could ship curl.wasm as a fallback and focus on the product
more than on the plumbing.

BTW, Dennis, could you see WordPress recommending a WASM extension if PHP=
bundled one here? https://make.wordpress.org/hosting/handbook/server-envir=
onment/#php-extensions

I'm not Dennis, but I think that's very real. If PHP had a solid,
official, viable WASM extension today, I'd already have a PR proposing
shipping WASM binaries with WordPress core. I'd also be advocating
everywhere to officially include the WASM PHP extension on the list of
WordPress-recommended extensions. And if that extension was a part of
every PHP build, I'd be advocating to list it as a requirement.

[1] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPres=
s/AsyncHttp/Client.php

Adam

29 days ago by Rowan Tommins [IMSoP] — view source

unread

If PHP had WASM support,
WordPress could ship curl.wasm as a fallback and focus on the product
more than on the plumbing.

As has been pointed out a couple of times already, this particular use
case really doesn't stand up to scrutiny.

The chances of PHP making it a requirement that everybody who installs
the PHP runtime must also install a WASM runtime are close to zero.
It's actually much more plausible (though still unlikely) that we would
make libcurl a hard requirement.
Hosts who do not install ext/curl because they don't trust it are very
unlikely to trust something as complex and versatile as a WASM runtime.
Hosts who do not install ext/curl because they only install the base
package provided by Ubuntu/RedHat/Alpine/etc won't install an ext/wasm,
because it won't be included in that base package. I can't stress enough
that those base packages are not "the default build of php-src", they
are entirely controlled by the package managers at each
distribution/repository.
Hosts who already install a variety of PHP extensions will already
install ext/curl, so are not relevant for this particular example.

The use case I can see is for high-end hosting services, who already
install a range of extensions, including ext/curl, but don't allow users
to upload binaries. (Mike gave the example of Pantheon.) They might
allow users to upload and run more niche extensions, if it was proven
that WASM provided a better sandbox than just running binary code inside
an OS container.

I don't actually know what market share that kind of service has, with
cheaper shared hosts on one side, and container-based hosting like
DigitalOcean (where you can upload native binaries already) on the other.

Regards,

--
Rowan Tommins
[IMSoP]

29 days ago by Dennis Snell — view source

unread

Thanks for your thoughtful response, Mike. I hope everyone had a nice weekend.

However, my guess is that Automattic (spelled correctly) is not likely to do that given how dismissive PHP Internals and by extension the PHP Foundation has been regarding the needs of WordPress users for as long as you Arvids have been doing PHP.

But who knows, maybe there could be a détente? Who on this list would be more open than in the past to treat concerns of WordPress users as legitimate rather than dismiss them because (I am paraphrasing) "how bad their code is?"

At Automattic we’re used to working in the open. With WordPress itself (apart from Automattic) even more so. Dismissal is my bread and butter 😄 But we’re still working hard to make the web a better place and I’m happy to partner with anyone, even if we share disagreement.

Or the ones who want to target the users of the CMS or Framework that recommend or require the extension.

If the extension were bundled then I expect it could become a recommended extension for hosts to enable and WordPress could start shipping WASM extensions for the use-cases Dennis Snell mentioned that can optionally run if the WASM extension is enabled vs. if not it would just run the old slower PHP code.

BTW, Dennis, could you see WordPress recommending a WASM extension if PHP bundled one here? https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions

Absolutely, though realistically we’re still talking about years before it could be required. We’re not going to alienate a broad swatch of the internet just to get a new feature. But WordPress has become more assertive in pushing updates, both on users and on hosts. There is a component of the decision that depends on how many sites are still using old versions and there is a component that looks at things like security issues, whether a version is supported, and whether hosts offer the newer versions.

WordPress today requires PHP 7.2.24, though that’s hidden in a paragraph of text after stating that the recommended minimum is 7.4. I believe that the update cycle has been contracting over time and the ecosystem is doing a much better job today at keeping updated than it was a decade ago.

My guess is that we could see rapid adoption of some WASM extensions and add it to the recommended list. This is my opinion though, and other maintainers may disagree.

How would we handle the JS-like stdlib of assembly script? Another abstraction layer? That seems easier to you than a DSL created specifically for this?

At this point I am realizing I might have completely misunderstood the original tangent into WASM. For one, I also find the idea of a DSL surprising for the needs being discussed. I’d like to understand better what this means, or what kind of extension would benefit from such a DSL, and what stage of the build this is being discussed (for example, a DSL for more easily writing PHP extensions in C, or a DSL like eBPF which PHP code can build as a string and submit for processing internally).

With PHP like syntax?

Why is "PHP like syntax" a blocking requirement? C does not have a PHP-like syntax, or at least one that is not more similar to AssemblyScript than PHP. Why then is C acceptable for extensions but AssemblyScript is not?

And even so, there is no reason a PHP-like syntax is required. PHP developers work with JS or TS every day, and AssemblyScript is just a variant of TypeScript.

What does it mean to build a WASM runtime for AssemblyScript? When I think about it, I consider a real black-box implementation with basic means of transferring primitive data types across the barrier. In JS we have numbers and shared memory buffers. This leaves many things wanting, but also is “enough” and makes the security domain much smaller and easier to ensure.

I’m not sure how to visualize what people are discussing when they talk about designing something for AssemblyScript. Would that exclude the ability to run C applications or Rust applications compiled to WebAssembly?

Once CMS & Frameworks are empowered to use WASM as part of their core offering then they could start recommending WASM and managed web hosts that want to cater to their users would start offering WASM enabled on their platforms.

BTW, very few CMS or Frameworks make any extensions not referenced in production.ini as requirements, and for very good reason because doing so would be too risky.

We can flip the discussion, too. The idea of running code on a WASM runtime from PHP isn’t just about stuffing new complexity into PHP. The day we require a WASM runtime is the day we can drop almost every other PHP extension from the required list. It’s great having curl and exif and pcre available, but the fact that they may not be makes every call out to them a liability - every call needs to a fallback implementation in user-land PHP or else we’re going to have to deal with site crashes.

Even extensions like mb_string are incredibly useful, but only because we don’t have access to tools that better fit the needs we have as a CMS. There are some very surprising code snippets that exist (a) because mb_string isn’t guaranteed to be there and (b) because the interface is close enough to look right but different enough to be extremely awkward.

One quick example comes up from just two nights ago: detecting URLs. We want to have a Unicode-aware strspn() function, so we have to use PCRE with the Unicode flag set. Now we have dependencies on extensions and no practical fallback, also the code in JavaScript cannot be the same because they use different regular expression syntax and people have to manually and correctly translate that. (Well, I have proposed some user-space PHP code to provide a streaming UTF-8 decoder, but it’s much slower than the C code inside PHP or the WASM binary would be). One new algorithm, compiled to WASM, could return the byte-offsets into a string where URLs are detected and then the PHP and JS could have a stable agreement and it wouldn’t depend on any other extensions than WASM.

Having spent years dealing with text encoding issues I’d cheerly replace existing mb_ code in WordPress with custom functionality as a WASM module. And again, I want to highlight that this is a win for hosts. Nobody needs to ask their host to install new extensions, no host has to evaluate the security or reliability of an extension. Nobody has to come begging for a rapid update to openssl because some vulnerability gave internet visitors root-level access on the host’s server. Nobody has to be disappointed because their host refuses to make libvips available to PHP code for the one site on their service that wants it. Hosts can start removing extensions that have long been headaches but are so necessary in practice that they can’t get rid of them.

——

This was supposed to be a very brief response. Sorry, and thanks for your patience reading through to the end. I’m responding because I feel like the conversation is relevant and good, but my tone is meant to be friendly with a realizing that none of this stuff is likely happening rapidly, and nobody is demanding this work. I want PHP to grow and mature, as I hope all here do, and I’m sharing where I can see WASM being the missing piece that we’ve wanted or needed for a long time to relieve pressure from the core language and escape from many of the legacy warts that make building reliable performant software in PHP so difficult.

Warmly,
Dennis Snell

29 days ago by Rowan Tommins [IMSoP] — view source

unread

I think there's an impression that somehow by proposing that "we" add
some complex functionality "to the language", it will suddenly
attract developers and become stable and universally adopted; but
it's really the other way around: once there's a mature
implementation, and some people offering to maintain it, we can
consider moving it to the php-src repo, if that seems beneficial.
(And if other constraints are met, such as licensing.)

No, it is not "the other way around," it is both, and
mischaracterizing it to say that the only way hosting providers will
install something is if it becomes popular dismisses the valid
approach we've been advocating for, or at least for installations on a
reasonably widespread basis (~1/3rd of hosts or more)

I didn't say it needed to be popular before it moved to php-src, I
said it needed to be mature. There's two reasons I think that:

If being "bundled with PHP" is seen by users and hosts as a stamp of
approval, we don't want to put that stamp on something incomplete or
insecure. Nor do we want to add code to php-src which nobody is
volunteering to maintain.
Once an extension is moved into php-src, it is limited to PHP's
release cycle - 1 feature release per year, and breaking changes only in
major releases every 5 years or so. Early on in a project, it's common
to make many more incremental releases, and have short deprecation
periods while you experiment with the API.

What your dismissal ignores is that many hosts won't install something
unless a Framework or CMS requires or at least recommends it. And no
Framework or CMS that cares anything at all about risk management —
e.g. none with a large userbase — would require or at least recommend
an extension that is not bundled with PHP unless there is overwhelming
need for it and it targets a business vs. a technical need.

From what I can see, that's not actually true. WordPress, as discussed
elsewhere on this thread, has a very small list of required
extensions, and a much longer list of "highly recommended" ones.
https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions

As well as "bundled with PHP" extensions such as ext/curl and ext/dom,
the "highly recommended" list includes third-party / PECL extensions
such as igbinary and imagick.

On the hosting side, you mentioned Pantheon as an example, who I admit I
hadn't heard of before. I couldn't find a concise list of supported PHP
extensions, but did find this sample phpinfo() output:
https://v83-php-info.pantheonsite.io/

Among the installed PECL extensions are igbinary, imagick, mongodb,
msgpack, and oauth (which I note lists the version as "2.0.8dev").

Meanwhile, extensions which are bundled with PHP but not installed on
Pantheon include ext/dba, ext/gd, ext/ffi, ext/pspell, ext/sysvmsg,
ext/sysvsem, and ext/sysvshm

Clearly they have a policy for which extensions to install that is not
driven by whether they ship in php-src or PECL.

Then let us redirect our discussion as to whether it would be
beneficial to adopt wasmer-php into php-src repo, an objective list of
reasons it would not, if not, and an objective list of things it could
do to resolve those objections.

We can certainly do that. I'm not sure if there's a strict checklist,
but from my understanding, here's a few of the things we'd need to consider:

Licensing - Could PHP legally distribute the extension?

Wasmer-PHP is under the MIT License, so should be fine.

Stability & Maturity - Is the extension ready for production use? Is it
in a state where one feature release per year will be sufficient?

Wasmer-PHP describes itself as "complete and mature", so seems
promising at a glance.

Portability - does the extension support the platforms PHP supports?

The compatibility table in the readme shows only Linux and Darwin on
amd64, with Windows support notably lacking. I'm not sure if this would
be considered a show-stopper.

Dependencies - What is needed to build and run it? Does that present any
licensing and portability concerns?
~ The extension itself seems to be self-contained C code (no C++, Rust,
or additional build tools). I haven't looked into the runtimes that it
would interface to.

Maintenance - is there somebody, and ideally several people, actively
responding to bug reports and compatibility updates? [See
https://github.com/php/php-src/blob/master/EXTENSIONS]

This looks like a problem; the last release was over 3 years ago, and
there doesn't seem to have been any activity on the public repo since.

I also can't see any mention of it on the main Wasmer project site at
https://wasmer.io/products/runtime or the docs at
https://docs.wasmer.io/ The Wayback Machine shows the previous version
of their docs listed PHP as one of 8 "language integrations", but that
didn't carry across when they rewrote it last summer:
http://web.archive.org/web/20230608040408/https://docs.wasmer.io/ They
may be intending to come back to it later, but at the moment it seems
they are not dedicating any resources to it.

Regards,

--
Rowan Tommins
[IMSoP]

28 days ago by Christoph M. Becker — view source

unread

Among the installed PECL extensions are igbinary, imagick, mongodb,
msgpack, and oauth (which I note lists the version as "2.0.8dev").

Well, oauth hadn't had a release for four years, so that probably has
been a last resort to still provide a working version. Not having new
releases for PECL extensions is a recurring problem.

Portability - does the extension support the platforms PHP supports?

The compatibility table in the readme shows only Linux and Darwin on
amd64, with Windows support notably lacking. I'm not sure if this would
be considered a show-stopper.

No, not necessarily. We have a couple of non Windows extensions already
bundled (e.g. posix).

Maintenance - is there somebody, and ideally several people, actively
responding to bug reports and compatibility updates? [See
https://github.com/php/php-src/blob/master/EXTENSIONS]

This looks like a problem; the last release was over 3 years ago, and
there doesn't seem to have been any activity on the public repo since.

Right, the project looks abandoned.

I also can't see any mention of it on the main Wasmer project site at
https://wasmer.io/products/runtime or the docs at
https://docs.wasmer.io/ The Wayback Machine shows the previous version
of their docs listed PHP as one of 8 "language integrations", but that
didn't carry across when they rewrote it last summer:
http://web.archive.org/web/20230608040408/https://docs.wasmer.io/ They
may be intending to come back to it later, but at the moment it seems
they are not dedicating any resources to it.

https://github.com/wasmerio/wasmer still links to
https://pecl.php.net/package/wasm, though.

Christoph

29 days ago by Larry Garfield — view source

unread

I absolutely love that Larry called the question if it were technically
possible. Maybe Larry will read this and can answer the question —
since he was heavily involved with Drupal — "Would Drupal be willing to
require or at least recommend a 3rd party WASM extension vs. a bundled
one here?
https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions";

To clarify since I was called out by name: I have had no involvement in Drupal in 7 years, have no interest in being involved in Drupal, would be perfectly happy to see the Drupal project fail and its leadership go bankrupt (for reasons that are entirely personal/social, not technical), and thus have no insight into what Drupal would or would not be willing to require.

--Larry Garfield

1 month ago by Rowan Tommins [IMSoP] — view source

unread

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]

1 month ago by Hammed Ajao — view source

unread

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

1 month ago by Adam Zielinski — view source

unread

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

1 month ago by Hammed Ajao — view source

unread

On Wed, Sep 18, 2024, 5:16 a.m. Adam Zielinski <
adam.zielinski@automattic.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

1 month ago by Mike Schinkel — view source

unread

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:

And even:

https://docs.docker.com/desktop/wasm/

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

1 month ago by Rowan Tommins [IMSoP] — view source

unread

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]

1 month ago by Mike Schinkel — view source

unread

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.

Sigh. I did not include all potential examples. Leave it to you to limit your characterizations to only the ones I included.

Here is another:

https://github.com/wasmerio/wasmer-php

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.

Moot point as it cannot be run on a managed hosted server.

https://github.com/extism/php-sdk

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.

So why do you claim that bundling a third-party dependency is a "never going to happen" scenario?

By that logic PHP would have none of these functionalities:

• cURL
• GD
• PDO
• OpenSSL
• MBString
• Zlib
• Zip
• XSL
• EXIF
• BCMath

And PHP would be much less useful without any one of them.

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.

Seems you do not actually understand WASM runtimes.

While WebAssembly is available "out of the box" in JavaScript-based runtimes like Node.js, Deno, and Electron, it is not limited to them. Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to be run as a general-purpose compute target, outside the scope of a JavaScript engine.

Shared hosting for php gets you the worst possible version of php. Can't recompile to enable any bundled extension, can't install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won't even be able to use?

To be clear, shared hosting and managed hosting can be VERY different animals.

I am advocating for enterprise-level managed hosting — like Pantheon — not shared hosting like GoDaddy.

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.

You did not say that explicitly, but you strongly implied it. Had you not meant to imply it then you'll argument would have made little sense because you would been implicitly admitting there are other uses for 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.

Here you go:

https://github.com/wasmerio/wasmer-php

BTW, as you being a C++ developer your argument is rather cynical because most PHP developers do not have the skills to write PHP extensions or work with FFI, and it is not a skill that can be acquired in a few weeks worth of free time. So you saying "Just do it" can be seen by a cynical person as you attempting to shut down discussion by presenting a blocking task that you can be pretty sure is too high a technical bar for most PHP developers.

I do want to gain that skill, but I doubt that I will be able to any time in the near future, especially not with other work commitments.

https://docs.docker.com/desktop/wasm/

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?

Shipping as a container runtime without the surrounding support of a host is a bit more complicated than implementing within a host.

By your argument Node, Deno, and Wasmer would not have been able to ship WASM support yet.

You can't do shit on a managed server, that is not the bar at all.

Who made you the arbiter of what the bar should be for the needs of other people?

What makes you so sure that wasm will be allowed on managed hosts? What's the incentive for providers to allow it?

The incentives would be market differentiation and customer demand.

For security reasons it does not matter if customers demanded FFI or extensions written in C, there is simply too much risk.

But if there were a sandboxed secure runtime shipped with PHP, especially one that could be memory-limited and CPU-throttled, then it would be easy for some managed hosts to decide to enable it. Not all would, but channeling your imagined role as arbiter, I would say that is not "the bar."

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.

When did I or anyone proposing WASM for PHP suggest that making compiling extensions into WebAssembly would necessarily be a blocking requirement?

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).

Or, simply allowing AssemblyScript as the initial way to use WASM in PHP core.

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.

Then for those cases where it is redundant, don't use it.

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.

Many hosts already whitelist php extensions. That does not help.

The use-case being discussed by me and the others who commented in support of WASM is primarily bespoke code written for project-specific requirements.

I am not saying WASM has to be the thing to meets that need, but AFAIK there is no other potential similar solution that could address it. You can dismiss that goals as being unimportant or "not making sense," but that does not mean there are not those who find meeting that need to make a lot of sense.

Let me turn it around then and ask that — rather than being the gatekeeper against a solution— you instead propose a solution to address all the following requirements:

Ability to run some form of module/add-in/extension/whatever-you-want-to-call-it in PHP that:

Ships with PHP code so those managed hosts who want to enable it can easily do so,
Allows for fully-bespoke project-specific things to be developed,
Is reasonably easy to program in a secure way (not C or C++),
Enables near native performance for things like looping and string manipulation and maths, and
And is secure, can limit memory use, and can throttle CPU hogging so hosts will not object to enabling it.

Since you have already dismissed WASM as not the right approach, how would you alternately address those requirements?

-Mike

1 month ago by Rowan Tommins [IMSoP] — view source

unread

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.

Moot point as it cannot be run on a managed hosted server.

Why not? Only because the people managing that server haven't been persuaded to include it as an option. And that is mostly because it's currently experimental, and there isn't wide demand for it.

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.

So why do you claim that bundling a third-party dependency is a "never going to happen" scenario?

By that logic PHP would have none of these functionalities:

• cURL
• GD
• PDO
• OpenSSL
• MBString
• Zlib
• Zip
• XSL
• EXIF
• BCMath

None of those are "built into PHP core" in the sense of "every copy of PHP includes them". Nor do any of them bundle their third-party dependencies.They are all optional extensions, which the user has to provide the dependencies for if they want to install and enable them.

They are what is sometimes referred to as "bundled extensions", which just means they have source code in the php-src repository, and get new releases at the same time as PHP. Being in that list doesn't mean managed hosts have to provide them (who would force them?) and not being in that list doesn't mean managed hosts can't provide them (it's as easy to install "php-mongodb" on Ubuntu as "php-mysqli", even though one is "bundled" and the other hosted on PECL).

Being "bundled" may be interpreted as something of a "stamp of approval", indicating that an extension is mainstream and stable. That's something that has to be earned - many extensions started out in their own projects, with releases listed on PECL or elsewhere, and were proposed for adoption into the php-src repo once they became stable.

Which is why I say your energies for now are best spent on a project like extism, or wasmer-php - build that stable extension, and then we can discuss whether it would be beneficial to adopt it into the php-src repo.

Seems you do not actually understand WASM runtimes.

While WebAssembly is available "out of the box" in JavaScript-based runtimes like Node.js, Deno, and Electron, it is not limited to them. Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to be run as a general-purpose compute target, outside the scope of a JavaScript engine.

I absolutely understand that; I already said that it will be interesting to see how projects like extism develop, making use of those runtimes to run alongside other languages. But as far as PHP, or Python, or Java, is concerned, those runtimes are an external process or library that is being interfaced. Integrating with them is no different, in principle, from integrating the driver for some new kind of database.

Which is great; it means you don't need any approval from this list, or to write up an RFC, you can get involved in building that integration right now, wherever people are working on an extension to enable it.

Regards,
Rowan Tommins
[IMSoP]

1 month ago by K Sandvik — view source

unread

Personally, for me, wasm becomes very interesting when we have dedicated CPU architectures that handle the wasm op codes natively in server farms. Otherwise, wasm is nice for mix-and-match language use or cleaning up systems with poor memory handling but not super-critical. Just my own personal opinion. --Kent

1 month ago by Hammed Ajao — view source

unread

On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP] <
imsop.php@rwec.co.uk> 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.

Sigh. I did not include all potential examples. Leave it to you to limit
your characterizations to only the ones I included.

Here is another:

https://github.com/wasmerio/wasmer-php

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.

Moot point as it cannot be run on a managed hosted server.

https://github.com/extism/php-sdk

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.

So why do you claim that bundling a third-party dependency is a "never
going to happen" scenario?

By that logic PHP would have none of these functionalities:

• cURL
• GD
• PDO
• OpenSSL
• MBString
• Zlib
• Zip
• XSL
• EXIF
• BCMath

And PHP would be much less useful without any one of them.

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.

Seems you do not actually understand WASM runtimes.

While WebAssembly is available "out of the box" in JavaScript-based
runtimes like Node.js, Deno, and Electron, it is not limited to them.
Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to
be run as a general-purpose compute target, outside the scope of a
JavaScript engine.

Shared hosting for php gets you the worst possible version of php. Can't
recompile to enable any bundled extension, can't install any new
extensions, so how exactly would you approach this? Wasm bundled with the
engine by default? Or some kind of opt in mechanism that shared hosters
won't even be able to use?

To be clear, shared hosting and managed hosting can be VERY different
animals.

I am advocating for enterprise-level managed hosting — like Pantheon — not
shared hosting like GoDaddy.

Ah so you want to make huge changes to the engine for even less users?

On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel mike@newclarity.net
wrote:
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.

You did not say that explicitly, but you strongly implied it. Had you not
meant to imply it then you'll argument would have made little sense because
you would been implicitly admitting there are other uses for it.

I can't tell if you're fucking with me or not. I wasn't commenting on
whether or not there are other uses for wasm, that has nothing to do with
my point. " 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.

Here you go:

https://github.com/wasmerio/wasmer-php

BTW, as you being a C++ developer your argument is rather cynical because
most PHP developers do not have the skills to write PHP extensions or work
with FFI, and it is not a skill that can be acquired in a few weeks worth
of free time. So you saying "Just do it" can be seen by a cynical person as
you attempting to shut down discussion by presenting a blocking task that
you can be pretty sure is too high a technical bar for most PHP developers.

I do want to gain that skill, but I doubt that I will be able to any time
in the near future, especially not with other work commitments.

https://docs.docker.com/desktop/wasm/

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?

Shipping as a container runtime without the surrounding support of a host
is a bit more complicated than implementing within a host.

If you insist, I'll await your MVP.

By your argument Node, Deno, and Wasmer would not have been able to ship
WASM support yet.

Node and Deno do not implement wasm, V8 does. They are both V8 wrappers. V8
implements it for the browser. Wasmer is at 17000 commits. Can we afford
17000 commits focused on wasm stuff? In core?

You can't do shit on a managed server, that is not the bar at all.

Who made you the arbiter of what the bar should be for the needs of other
people?

Common sense, majority of use cases, and history.

What makes you so sure that wasm will be allowed on managed hosts?
What's the incentive for providers to allow it?

The incentives would be market differentiation and customer demand.

So maybe those companies should implement it themselves or pay to have it
implemented.

For security reasons it does not matter if customers demanded FFI or
extensions written in C, there is simply too much risk.

So maybe those companies should implement it themselves or pay to have it
implemented.

But if there were a sandboxed secure runtime shipped with PHP, especially
one that could be memory-limited and CPU-throttled, then it would be easy
for some managed hosts to decide to enable it. Not all would, but
channeling your imagined role as arbiter, I would say that is not "the
bar."

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.

When did I or anyone proposing WASM for PHP suggest that making compiling
extensions into WebAssembly would necessarily be a blocking requirement?

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).

Or, simply allowing AssemblyScript as the initial way to use WASM in PHP
core.

How would we handle the JS-like stdlib of assembly script? Another
abstraction layer? That seems easier to you than a DSL created specifically
for this? With PHP like syntax? Using the parser already in the engine?
With a PHP-like stdlib?

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.

Then for those cases where it is redundant, don't use it.

That's most use cases. It doesn't make any sense to burden all users and
contributors just so some companies can maybe decide to enable wasm to make
more money.

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.

Many hosts already whitelist php extensions. That does not help.

The use-case being discussed by me and the others who commented in support
of WASM is primarily bespoke code written for project-specific requirements.

I am not saying WASM has to be the thing to meets that need, but AFAIK
there is no other potential similar solution that could address it. You
can dismiss that goals as being unimportant or "not making sense," but that
does not mean there are not those who find meeting that need to make a lot
of sense.

Let me turn it around then and ask that — rather than being the gatekeeper
against a solution— you instead propose a solution to address all the
following requirements:

Ability to run some form of
module/add-in/extension/whatever-you-want-to-call-it in PHP that:

Ships with PHP code so those managed hosts who want to enable it can
easily do so,

Allows for fully-bespoke project-specific things to be developed,

Is reasonably easy to program in a secure way (not C or C++),

Enables near native performance for things like looping and string
manipulation and maths, and

And is secure, can limit memory use, and can throttle CPU hogging so
hosts will not object to enabling it.

Since you have already dismissed WASM as not the right approach, how would
you alternately address those requirements?

Honestly, a DSL would be the perfect solution here. Anyone familiar with
writing PHP extensions knows about gen_stub.php, which scans PHP stubs
and generates the corresponding binding C code. I've often thought this
process could be extended to handle more complex scenarios like promoted
properties, simple expressions (e.g., assignments, property access,
comparisons), and anything that can be easily translated into C code.

V8 has a similar tool called Torque, and I've always wondered what
something like that would look like for PHP. It would result in a strict,
statically typed subset of PHP that satisfies all the requirements, except
for the last one (which it would only partially fulfill).

Since the generated code would interface directly with the Zend API, we can
consider the DSL code as safe as the PHP implementation itself. While there
wouldn't be CPU throttling, hosts shouldn't have major objections since it
would essentially be as safe as PHP.

Most importantly, this approach would benefit everyone. It would have no
third-party dependencies and would only need to evolve alongside PHP/Zend
as they grow.

That’s how I would approach it.

Hammed

1 month ago by Hammed Ajao — view source

unread

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.

https://www.webassembly.guide/webassembly-guide/webassembly/webassembly-in-the-server

https://blog.pixelfreestudio.com/how-to-implement-webassembly-in-server-side-applications/

https://medium.com/wasm/webassembly-on-the-server-side-c584f874b4a3

https://www.secondstate.io/articles/why-webassembly-server/

https://www.techtarget.com/searchitoperations/news/252527414/Server-side-WebAssembly-prepares-for-takeoff-in-2023

And even:

https://docs.docker.com/desktop/wasm/

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.

1 month ago by Rowan Tommins [IMSoP] — view source

unread

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]

1 month ago by Mike Schinkel — view source

unread

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:

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,
Constantly improving PHP the language, which is what you are solely advocating for over extensibility,
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,
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
Typedefs FTW!

-Mike