Re: [DISCUSSION] C++ Enhancements in Zend API

From: Date: Mon, 12 Aug 2024 20:58:54 +0000
Subject: Re: [DISCUSSION] C++ Enhancements in Zend API
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Friend, honest to god you are really not doing yourself any favors here.

You came on this list with a proposal. I think it's a bad idea, and I've enumerated the
reasons why I have come to that conclusion:
If it's so easy and transparent to improve support for C++, it could easily exist outside of
core as a set of header files to make the lift lighter for someone looking to use it. Sounds like
that project already exists (no idea, didn't look into it).
Even if it's "easy" with a few header files, it's still adding a whole new thing
required to maintain the project because now someone has to own and maintain a C++ API and every
change to the "real" C engine needs a corresponding C++ API update. Who here long-term is
going to own that engine-level API and make sure it's "the C++ way"...you? The way
you're behaving I wouldn't trust you to not rage-quit today... so who then? What happens
if there is a conflict between "the C way" and "the C++ way" in regards to a new
engine-level API down the road? What kind of extra thought / energy / consideration do we need to
put into engine-level API changes in the future because now we have to maintain two distinct engine
APIs?

If it's not so easy and transparent (e.g. requiring us to start modifying the engine because
C++ isn't happy), I'm opposed to the idea because conceptually I'd like to see any
such effort spent on improving support for a future-looking language. I honestly don't care
what that is, but considering Linux's recent embracing of Rust I think that's got some
merit to consider. For the record, I don't personally even code in Rust so attacking me like
I've got a horse in that race is pretty ridiculous.

I don't believe that just because something is prevalent means it's good. Entire
governments are starting to recommend not using C/C++ because of the security risks posed by its
non-existent memory safety. If PHP was being written today, it wouldn't have been written in C.

Don't like I don't agree with you? Okay. It's a public mailing list, and everyone
here has an opportunity to chime in and voice their opinion. I'll give you a nickel's
worth of free advice though -- speaking from personal experience I'd be happy to tell you about
over a beer one day -- not only are you violating the rules of the list, but you're not helping
your cause and you just look like an @!#%$% who is screaming louder and louder because someone
doesn't agree with them. Please stop, for your own sake.

What is 100% clear to me is that, even if there is a good reason to go down this road, IMO it
absolutely should go through an RFC process as I said up front because just with what I've
thought of enumerated above there are a lot of questions here that I don't see any reason to
believe you've thought through, even if I try to ignore your constant insults.


Thread (40 messages)

« previous php.internals (#124908) next »