On Aug 12 2024, at 12:27 pm, Lanre <lnearw...@gmail.com> wrote: > > > On Mon, Aug 12, 2024 at 9:58 AM John Coggeshall <j...@coggeshall.org > (mailto:j...@coggeshall.org)> wrote: > > > > > > I’m considering adding some C++ enhancements to the Zend API. > > I would definitely like to see an RFC for this if it was to be considered. > > To me, adding a whole new way of doing things internally without completely > > removing the old way is just asking for a more brittle, potentially less > > secure, and harder to maintain codebase. The win of making it easier / > > "nicer" on a subset of developers who might prefer a C++ interface isn't > > anywhere near worth the risk IMO. > > You aren't making any sense. Why would we remove the old way? Or why should > that be a prerequisite to improving the current API? How are functions that > simply proxy the C API inherently 'more brittle, potentially less secure, and > harder to maintain'? You haven't even seen the code in question?
I think I'm making perfect sense. I don't think it's a good idea to have two ways of doing the same thing. Having two ways means twice the tests, twice the potential security issues, and twice the maintenance. This is not a simple thing you are suggesting -- I highly doubt any move to C++ is going to end as a simple wrapper (which I assume is what you're implying by your code block), even if the first PR merged starts that way. FWIW I agree 100% with Pierre as well -- both his political and non-political answer :) -- if the project was to consider anything I'd love to see Rust get some love.
