On 11 August 2024 23:52:00 BST, Lanre <[email protected]> wrote:
>I’m considering adding some C++ enhancements to the Zend API. These changes
>would be encapsulated within #ifdef __cplusplus guards, so they wouldn’t
>interfere with the existing C implementation. The primary goal is to
>provide a nicer interface for extensions while maintaining compatibility
>with C.
Hi Lanre,
This thread seems to have become quite heated, perhaps because people tend to have strong opinions
about different programming languages.
It might help reset the discussion to draft a quick RFC outlining what is being proposed, and why.
I think some key things that would need to be considered are:
1. Why does this belong in the core repository, vs a separate library such as PHP-CPP? Would it be
easier to have it maintained by people familiar with the core engine, but not with C++, rather than
people outside the project, but familiar with C++? Are there technical reasons why some features
require / benefit from being part of the same files / directories as the C API? Are there potential
uses for things which are already in the core, such as bundled extensions?
2. Does this imply the PHP project "blessing" C++ in some way, over other languages? Or
does it imply we could/should have similar wrappers for other languages, such as Rust and Go?
(Ignoring any personal views, both are in active use in similar contexts, and a quick search turned
up https://docs.rs/ext-php-rs/latest/ext_php_rs/
and https://github.com/deuill/go-php)
3. What guarantees can/should we provide about the stability and maintenance of these additional API
elements? Note that this crosses over with point 1 - a separate library can make breaking changes on
a different cycle to the core project, and even add C++ (or Rust, Go, etc) APIs for already released
versions of the engine.
Regards,
Rowan Tommins
[IMSoP]