Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125651 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 6B8B21A00BD for ; Sat, 21 Sep 2024 00:51:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726880015; bh=+qgYeCAfyyiYQbjVaoyYdkBB0D1GLz+FmiaIk02kRF4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GWeNk9S6jIWw+BT/qhYlZgl3xcxD5+ZmAq4w8AD0bIWUbWL2RSEPYzYqEonByc2aO PjWosrJS9JcCgjiPEDakLYIaiWLNa3HZLsgOkfDmBEYSTSsy3t3DDOwWZPG1me9R2F BIf2c/wZHCzIgMpBzrOCFG7M+sQJ/+FgfOhf9vG+SR5nc9Kz0YEk4ku5lZufTqkpHB /leNO1cceEGeaTDBSLL4j69U1qQn/jhaFXhHaaD9Ti9+8u/E1daJvpWwbsiTEvktMJ JKexMrxhH2FxggS5//FqVP29ByIShVBDcLPAPSyGPdJfvebhSSr8AX7yR1az05WoJg x23POL1/aJnGA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CBEA5180042 for ; Sat, 21 Sep 2024 00:53:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 21 Sep 2024 00:53:33 +0000 (UTC) Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5e1b55346c0so1129054eaf.3 for ; Fri, 20 Sep 2024 17:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726879885; x=1727484685; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kJhTIed3MVUJSf9bdJL1MpFcv8OYKtOX/tR0NxNfZyE=; b=Ke4KP1vi9H4gGxWN6bkfWZVGJfNjL5dHbDrXTV7DCJkm0qnL35esftCV2HzG6oNt/1 GMg66MQmmYwiy+CcPgqTkUv1sgvkrbuS9kHTnoA6X3gRvZKKG2PT0OJVSY3jgaIoh+t8 H2AgBfEdAXSfLvEPlK9jRdDsF5UQIbrQ4AYoHCh8z2pFE8bo5hYAJMS2Wo+Tx6y7xGEr gxgBw2gl+b9zdQ83hN1SbSyDUQQ5PAxqlXc5s7dqLWnr6b+RBqknhxRoY1V7goDKOkxB 5QbSTjB5VZCwsc7JmEzgEIG+bwz0zK24JFEMT7q3VPzaHzoJXaMVqtEKUJrDcr1ErTqx czoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726879885; x=1727484685; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kJhTIed3MVUJSf9bdJL1MpFcv8OYKtOX/tR0NxNfZyE=; b=DgSEP8qCO5dB7KSxTwc7WTXdHbWRi2no9Oc0/jVIY/GLpnfKjPM+vjKjenuf1VGejz 6ThcKur7GhZjcI5ElBIQUPgbEB8RR+xGj7lGUCG0AXavswb9bLlgZ5FxCo6rv+mj0Bhz 8toc6cGgf/XubRczUARo9O0X7dErV4sVab+0FTxdUBDsIKCxR5Mc6619/T7F7jw72Th4 MLtH9a2tQbHv4HLdlUmFRzr+uo5vaQhv7GG8CYnarN9n++FOeErpG9f83Tg42m+fMY88 wCJWlIqMzG8MLemLfRLhMxOf9W8KVdKsy3CxeBKUClWydX8t62xDyM2W/NQ/j5mXggvH OkDQ== X-Forwarded-Encrypted: i=1; AJvYcCVYaFEwpJCwhJvT6Tdy8bZh/OpvkctLpQsBDYh8Tgc+EqgihHWxnCkF6n6P5LQFyBpz9uicqIvX9ek=@lists.php.net X-Gm-Message-State: AOJu0YyFO5UpmYH504D1t+cO8nHZXTfqVdAydGBW8sNhcA8DSXvQVwyL wqQApBrsU++xx2X5mhvSJ/0MpPuGpGWQHmezn/XOWsBMp3hpNdQVL/5ALjuEwEWsLK3pPbhalr7 LkA6IVKYK35QMhkadmpYOaczJaOw= X-Google-Smtp-Source: AGHT+IEg1XLzHDPsvyvD6xPcvhikYt1jBw12JJ6haeB4jihYX/n5vciIwcFQAVvmRNvewXxpk3vDCjnSAscRjBXrU3I= X-Received: by 2002:a05:6870:8089:b0:26c:64f8:d6c4 with SMTP id 586e51a60fabf-2803a7b82c5mr3144801fac.38.1726879885420; Fri, 20 Sep 2024 17:51:25 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net> In-Reply-To: Date: Fri, 20 Sep 2024 18:51:14 -0600 Message-ID: Subject: Re: [PHP-DEV] Zephir, and other tangents To: Mike Schinkel Cc: "Rowan Tommins [IMSoP]" , Adam Zielinski , PHP internals , Dennis Snell Content-Type: multipart/alternative; boundary="00000000000023efda0622968e62" From: hamiegold@gmail.com (Hammed Ajao) --00000000000023efda0622968e62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 19, 2024 at 11:20=E2=80=AFPM Mike Schinkel wrote: > > On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP] < > imsop.php@rwec.co.uk> wrote: > > > > On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote: > >> Yeah. That was the original goal. > >> > >> But to say WASM's domain is limited to browsers is not valid any longe= r: > >> [...] > > > > While it's definitely interesting seeing what uses it's being put to > beyond the browser, the majority of those articles are talking about usin= g > WASM on its own, in the kind of places where you might use a container, t= o > 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 seem= s > 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 =E2=80=93 assuming it were b= uilt-in > >> to PHP core > > > > Just to reiterate, if by "built-in to PHP core", you mean "every copy o= f > 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-par= ty > 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: > > =E2=80=A2 cURL > =E2=80=A2 GD > =E2=80=A2 PDO > =E2=80=A2 OpenSSL > =E2=80=A2 MBString > =E2=80=A2 Zlib > =E2=80=A2 Zip > =E2=80=A2 XSL > =E2=80=A2 EXIF > =E2=80=A2 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 existin= g > runtime, not a whole new VM - like running Scala and Java code in the sam= e > 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. > > > On Sep 19, 2024, at 4:41 PM, Hammed Ajao wrote: > > > > 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 =E2=80=94 like Panth= eon =E2=80=94 not > shared hosting like GoDaddy. > Ah so you want to make huge changes to the engine for even less users? > > > On Sep 19, 2024, at 4:12 PM, Hammed Ajao wrote: > > On Wed, Sep 18, 2024, 1:33=E2=80=AFp.m. Mike Schinkel > 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 becau= se > 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 wor= k > 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 developer= s. > > 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 exactl= y > 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=E2=80=94similar to AssemblyScript=E2=80=94or simpl= y 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 addin= g > 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 suppor= t > of WASM is primarily bespoke code written for project-specific requiremen= ts. > > 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 th= at > does not mean there are not those who find meeting that need to make a lo= t > of sense. > Let me turn it around then and ask that =E2=80=94 rather than being the g= atekeeper > against a solution=E2=80=94 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: > > 1. Ships with PHP code so those managed hosts who want to enable it can > easily do so, > 2. Allows for fully-bespoke project-specific things to be developed, > 3. Is reasonably easy to program in a secure way (not C or C++), > 4. Enables near native performance for things like looping and string > manipulation and maths, and > 5. 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 woul= d > 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=E2=80=99s how I would approach it. Hammed --00000000000023efda0622968e62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 19, 2024 at 11:20=E2=80= =AFPM Mike Schinkel <mike@newclarity.net> wrote:
> On Sep 19, 2024, at 12:00 PM, Rowan Tommins [= IMSoP] <imsop.= php@rwec.co.uk> wrote:
>
> On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:
>> Yeah. That was the original goal.
>>
>> But to say WASM's domain is limited to browsers is not valid a= ny 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 contain= er, to host things like microservices, serverless functions, etc.

Sigh. I did not include all potential examples. Leave it to you to limit yo= ur 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 =E2=80=93 assuming i= t were built-in
>> to PHP core
>
> Just to reiterate, if by "built-in to PHP core", you mean &q= uot;every copy of PHP includes a functional WASM runtime", that's = not going to happen. It would mean bundling (or requiring every user to ins= tall) a huge third-party dependency, with all of its dependencies and platf= orm 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?=C2=A0

By that logic PHP would have none of these functionalities:

=E2=80=A2 cURL
=E2=80=A2 GD
=E2=80=A2 PDO
=E2=80=A2 OpenSSL
=E2=80=A2 MBString
=E2=80=A2 Zlib
=E2=80=A2 Zip
=E2=80=A2 XSL
=E2=80=A2 EXIF
=E2=80=A2 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 o= f 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 ex= isting runtime, not a whole new VM - like running Scala and Java code in th= e same JVM; or Hack and PHP in (older versions of) HHVM.

Seems you do not actually understand WASM runtimes.=C2=A0

While WebAssembly is available "out of the box" in JavaScript-bas= ed runtimes like Node.js, Deno, and Electron, it is not limited to them. St= andalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to b= e run as a general-purpose compute target, outside the scope of a JavaScrip= t engine.

> On Sep 19, 2024, at 4:41 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
>
> 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 anima= ls.

I am advocating for enterprise-level managed hosting =E2=80=94 like Pantheo= n =E2=80=94 not shared hosting like GoDaddy.

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

> On Sep 19, 2024, at 4:12 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
> On Wed, Sep 18, 2024, 1:33=E2=80=AFp.m. Mike Schinkel <mike@newclarity.net> wr= ote:
> But to say WASM's domain is limited to browsers is not valid any l= onger:
>
> 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 m= eant to imply it then you'll argument would have made little sense beca= use you would been implicitly admitting there are other uses for it.

I can't tell if you're fucking with m= e or not. I wasn't commenting on whether or not there are other uses fo= r wasm, that has nothing to do with my point. " All I did was try to e= xplain to you why browsers need wasm and why it makes=C2=A0sense for them t= o invest in implementing it. "
=C2=A0

> But since you have all those guides and it's so practical, what= 9;s stopping you? You'd do a better job of convincing me with a MVP tha= n 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 m= ost PHP developers do not have the skills to write PHP extensions or work w= ith 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 p= erson as you attempting to shut down discussion by presenting a blocking ta= sk that you can be pretty sure is too high a technical bar for most PHP dev= elopers.

I do want to gain that skill, but I doubt that I will be able to any time i= n 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 eng= ineers haven't shipped wasm in 2 years, how long do you think it'll= take a bunch of volunteers?

=C2=A0
Shipping as a container runtime without the surrounding support of a h= ost is a bit more complicated than implementing within a host.
=

If you insist, I'll await your MVP.
=C2= =A0


By your argument Node, Deno, and Wasmer would not have been able to ship WA= SM support yet.
=C2=A0
Node and Deno do not = implement wasm, V8 does. They are both V8 wrappers. V8 implements it for th= e 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 p= eople?

Common sense, majority of use ca= ses, and history.=C2=A0
=C2=A0

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

The incentives would be market differentiation and customer demand.

So maybe those companies should implement it t= hemselves or pay to have it implemented.
=C2=A0

For security reasons it does not matter if customers demanded FFI or extens= ions written in C, there is simply too much risk.
=C2=A0
So maybe those companies should implement it themselves or pay to = have it implemented.

=C2=A0

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

> > Extensions, which are already implemented in lower-level language= s 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 e= xtensions 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=E2=80=94similar to AssemblyScript=E2=80=94or 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 co= re.

How would we handle the JS-like std= lib 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?
=C2=A0

> > In essence, WebAssembly is great for certain scenarios, but PHP h= as 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 s= ense to burden all users and contributors just so some companies can maybe = decide to enable wasm to make more money.
=C2=A0

> 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` woul= d be up for discussion. Or maybe we can bundle a small std lib of select ex= tensions 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 ther= e is no other potential similar solution that could address it.=C2=A0 You c= an 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 m= ake a lot of sense.=C2=A0

Let me turn it around then and ask that =E2=80=94 rather than being the gat= ekeeper against a solution=E2=80=94 you instead propose a solution to addre= ss all the following requirements:

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

1. Ships with PHP code so those managed hosts who want to enable it can eas= ily do so,
2. Allows for fully-bespoke project-specific things to be developed,
3. Is reasonably easy to program in a secure way (not C or C++),
4. Enables near native performance for things like looping and string manip= ulation and maths, and
5. And is secure, can limit memory use, and can throttle CPU hogging so hos= ts 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 wi= th writing PHP extensions knows about `gen_stub.php`, which scans PHP stubs= and generates the corresponding binding C code. I've often thought thi= s process could be extended to handle more complex scenarios like promoted = properties, simple expressions (e.g., assignments, property access, compari= sons), and anything that can be easily translated into C code.

V8 ha= s 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 la= st one (which it would only partially fulfill).

Since the generated = code would interface directly with the Zend API, we can consider the DSL co= de as safe as the PHP implementation itself. While there wouldn't be CP= U throttling, hosts shouldn't have major objections since it would esse= ntially be as safe as PHP.

Most importantly, this approach would ben= efit everyone. It would have no third-party dependencies and would only nee= d to evolve alongside PHP/Zend as they grow.

That=E2=80=99s how I wo= uld approach it.

Hammed
--00000000000023efda0622968e62--