> On Mar 23, 2020, at 3:08 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On Mar 23, 2020, at 1:51 PM, Ben Ramsey <b...@benramsey.com> wrote: > >>> I think Rowan is making the point that *most* of the features found in >> the core PHP distribution are *optional*. Distributions and hosts are >> choosing to enable them. There are very few things in the core distribution >> that cannot be disabled at build time. >>> >>> I’ve run into this numerous times in my userland OSS libraries. It came >> up recently with the ctype functions. Someone’s host had these disabled, >> for whatever reason, so I had to use a polyfill library to provide the >> functionality, for those cases. > > > Thank you, yes, that's exactly what I'm saying. PHP is, right now, a > modular product.
While that it technically true, but in practice there is very little variance across WordPress managed hosts. Why? WordPress has documented its required extensions and there are rarely motivations for hosts to go beyond that when they are offering WordPress hosting: https://make.wordpress.org/hosting/handbook/handbook/server-environment/#php-extensions And I assume Drupal has similar established extension requirements. > As long as that's true, there will be hosts who disable features you wish > they wouldn't. Some of those can be polyfilled directly (e.g. ctype), some > have to be painfully worked around (e.g. curl), and some are pretty much > impossible because no userland equivalent exists. Generally that is not the issue with WordPress. Most managed WordPress hosts support the required ones, and few managed WordPress hosts support anything more except for when they need the support for their own platform, which is the case with Pantheon's extra extensions. And even if one host does support more extensions, no responsible WordPress developer would use them (unless they are highly specific to business requirements) because if they did it could lock them into not being able to move off that managed host if needed. So yes PHP is technical modular, but among managed hosts PHP is a monolith. And yes, this is about WordPress, but the constraints of using WordPress' on managed hosts was the original premise of this thread. > Regarding choice of language for that mechanism, I'm not sure we need to > look any further than PHP itself: what we're really talking about is making > facilities available to the average user that are currently only available > to extension developers. If that is the case then we probably need to add more improvements to the PHP language than have been added in the past 10 years because there is so much you can't reasonably do in PHP. One example would be to adopt the gradual typing of Hack to allow for significant performance improvement. Said another way, I don't see PHP coming close to the performance of Rust anytime in the next (few) decade(s). > We've already made huge strides in one big > advantage, which is speed - if they were starting today, I wonder if the > Phalcon team would bother inventing Zephir, or if they'd just design the > framework with OpCache pre-loading in mind. It is notable you mention Zephir but make no mention to WASM, which is what I pointed to as the most promising extension mechanism I currently see on the horizon. (BTW, I am really happy they created Zephir, but only because it is helpful for a project I am working on in ways that would probably not be applicable to discuss on the list.) But why no reference to WASM? WASM would let us write extensions in many languages. Even better, we could write a PHP-to-WASM compiler for a WASM-specific dialect of PHP. > > > Regards, > -- > Rowan Tommins > [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
