On 11 August 2024 23:52:00 BST, Lanre <lnearw...@gmail.com> 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]
