John reached out to me directly, but i think he raised some valid points that I should address here, so here it is:
On Thu, Aug 15, 2024 at 1:56 PM John Coggeshall <j...@coggeshall.org> wrote: > Lanre, > > I think you're expectations are probably unrealistic if you expected to > drop a PR in a week to add C++ support as you describe, and expect it to be > immediately accepted (which is what I'm taking from your "I had a week off > to do this" comment). > Correct me if i'm wrong but aren't RFCs usually for changes that somehow affect userland or the API? This does neither and is fairly simple to implement so I assumed this thread would be more about implementation details and what branch to merge this to. It isn't unrealistic for me, but to each their own. > Also, I honestly couldn't care less how much money you make -- it doesn't > excuse your behavior on the list. > Never said it did, just letting you know the caliber of C++ dev I am,and that I am much more familiar with C++ than you are. I get paid a lot to do what I'm offering to do for free. I shouldn't have to privately message you in order for you to act with some > decorum in the Internals list -- it won't be me that does it, but I am > certain if you don't knock it off you'll just be removed eventually if you > keep it up. That's not a threat, it's just what eventually happens. > You most certainly did not have to message me privately. > But let's get back to the merits of what you are talking about. To be > entirely honest I really don't have the time to walk through all of it with > you, but I'll do my best to give you some insights that will help you be > successful in at least pitching your ideas to the community. > > First you have to understand that, generally speaking, there isn't a ton > of appetite to spend a lot of energy on C++ for internals.. That's largely > a historic issue, as I'd bet most of us are C devs first and PHP for better > or worse was written in C. That's not to say you're idea isn't worth > considering -- but it does mean you're going to face a bit of an uphill > battle. > Which is pretty ridiculous. I am not asking for anything too crazy and I shouldn't have to face an uphill battle when all I'm doing is maintenance. Why does it have to be personal? > > I'm not entirely clear what you mean when you say handling this at the > extension level is "breaking portability" -- in what sense do you mean? I'm > also a little confused by your statement "these new subclasses in each > extension"... subclasses of what parent class? > zval parent class. > Either way, anytime people start talking about messing around with zval, > you're going to get a lot of questions for obvious reasons. If you are > serious about this there are a few things you need to consider: > Which is why Ii'm not messing around with zval. Yes there will be a constructor and destructor, comparison operators as well as common methods, which will all be behind a C++ macro. Those are necessary changes > > - It matters to this project, and every open source project, that > there is a confidence that people will be around to maintain stuff other > people built. If you are the only person who is able to maintain something > you've put into core that's a big problem. I don't expect anyone to > maintain their code forever here, nor should you assume they will. I have a > nearly never-ending list of code across multiple open source projects where > someone showed up, wrote some code no one else could maintain for whatever > reason, and 6 mos later disappeared leaving the project holding the bag. > It's not that I don't think you understand code requires maintenance -- > it's that you don't seem to understand eventually you're going to probably > move on and leave and someone else is going to maintain your code... or > worse, your code goes unmaintained and the whole project suffers. > > What are you basing this on? You just read my proposal and instead of attacking the points I made, you are making baseless accusations. I don't get paid for this, so obviously I will only maintain it for as long as it interests me, which is completely fair. PHP Foundation exists and accepts donations for what exactly if not to pay devs to maintain php-src? > > - One of the ways to get past the issue above is to create confidence > around your idea that there is enough talent in the community to maintain > your code without you by clearly explaining in detail exactly what the work > is, why its important, and showing you've put the thought into long-term > maint of the changes as necessary. To wit; > > Why do you assume that no one else is capable of maintaining this? > > - I have a lot of questions about what your suggested implementation > (I assume basically you are suggesting your "Option A" becomes part of core > -- or something similar?) would mean for the codebase as a whole. Many of > these concerns stem from my first point above. Here are just two of them > that seem relevant immediately: > - Is this literally a wrapper around zval (allocated separately), or > are you proposing we start allocating zval s on an object creation? > > Yes, when implemented as an extension, it has to be a subclass of zval. If implemented in core though, it would be added directly to zval (under C++ guards). > - > - If we now have an object that represents a zval , does that mean > this object has methods that reflect the C function calls? e.g. is > there a > print method that maps to zend_print_zval ? > > C doesn't have methods. And maybe? That's part of the implementation details I was hoping do discuss. > > - > - If you are now introducing a whole new way to "print a zval" > (e.g. zend_print_zval(myZval) and myZval->print() , what is the > justification for a whole new API? > > A print method would fall under 'common methods' not a big deal, but it would improve readability in C++ code. > > - > - > - Who is going to maintain it? Right now we already have to > worry about API changes just dealing with the C level stuff... now > we've > doubled the problem because of C++ stuff if it also has a > method-based API. > > Me, until I get bored, then hopefully someone else. Is there a different way it's supposed to go? > > - > - > - There won't always been a clear translation of zend_print_eval > to print() , isn't introducing a new OO API on top of the > procedural one going to butt heads on some points? Who wins? > > How would it butt heads if it doesn't even work in C? Who would be butting heads exactly? I think i'm missing your point here. > > - > - > - What about the values inside of zval , do you propose proxying > access to those from this class? (e.g. myZval->v ) > > Nah, I propose myZval->String() for when the zval is a string (which should be determined by myZval->IsString()) and myZval->AsString() to proxy `convert_to_string`. That's a valid question. > > - > - If it's literally a class wrapper around a zval for linking or > whatever reasons to avoid the zend_print_zval vs. print issues, > what policies, defensive coding techniques, etc. do we need in place so > the > next guy 2 years from now doesn't think it's a good idea to add a > print method because he wasn't around for this whole discussion? > > There would be little downsides to adding a print member method, especially if all it does is call zend_print_zval.(other than more code we have to maintain, which again applies to all changes). > > - > - Is this proposal literally limited to zval or are you suggesting > a collection of classes around various engine structs? If the proposal > were > to be adopted to accept your zval class, would you propose other > changes? It seems like this is a never-ending road.. > > Finally -- let's be really clear here about something -- it's not the > community's job to say yes to you, it's your job to convince the community. > The best way you can do that is a well thought out RFC that shows the > community you have put in the necessary time and consideration to making > such a fundamental addition to the engine. > That is a ridiculous expectation to have on both sides. No, I don't expect the community to just say yes to me, but I expect valid reasons for saying no to my proposal, not just "someone will have to maintain it" and "C++ is obsolete so this is pointless". It is just as ridiculous as expecting me to whole RFC simply to introduce an idea. Even the RFC guide requires a discussion first, unless I am missing something. > No one, including me, is looking to make it unnecessarily difficult to use > C++ to write extensions, > Are you sure about that? > but the difficulty that exists today is because trying to come up with > smart solutions to questions such as above is hard. > Says who? > I certainly welcome you to contribute here if you believe you have a good > idea with the above in mind, as long as you can do it respectfully. > > > John > > On Aug 15 2024, at 2:50 pm, Lanre <lnearw...@gmail.com> wrote: > > Hi John, > > Thanks for reaching out to me directly—I really appreciate it. I’m a C++ > developer and don't work with PHP professionally; it’s something I do for > personal projects and scripts. I had a week off and decided to create > something that could make life easier for C++ developers like myself when > writing extensions. > > The issue isn’t just that certain implementations are repeatedly being > recreated; it’s also that this repetition breaks portability for C++ > extensions. You can't use standard library containers without ensuring your > class or struct adheres to specific rules. This leaves you with two options: > > > 1. Write a wrapper class that extends zval to make it compatible > (which is my usual approach). > 2. Override global operators for zval, which is problematic as you > still won't have a constructor or destructor. If another extension does > this, it’s undefined behavior. > > Option A works well, but I have to do this for each extension I write. The > problem is that even though these new subclasses in each extension are > practically identical, they’re not compatible with each other without > linking all the extensions or a common object file that defines this. This > introduces a dependency that isn’t Zend/PHP, which is why I don’t bother > shipping some of them. > > You seemed to assume I wasn’t willing to maintain my code—isn’t that a > given? Or do you think I believe code just works without maintenance? Your > point about someone needing to maintain APIs and ensure parity with C APIs > applies to any change made to the engine, so why keep bringing it up? > > You said this could be done outside the core, but that’s not true. If it’s > done outside, it will be incompatible with other external implementations. > This is part of my frustration. You write C++ "when the need arises"; > meanwhile, I’m paid $300k a year to do so. You lack the experience to > confidently say, "this could easily be done outside of core"—you’re > essentially guessing. How many C++ extensions have you written? How many > times have you encountered and solved this issue? > > I’m volunteering for this, with only a day left of my week off, which > means I probably won’t be pursuing the RFC until the next opportunity I > get. So, thanks for that. > > Lanre > > On Thu, Aug 15, 2024 at 12:13 PM John Coggeshall <j...@coggeshall.org> > wrote: > > Lanre, > > I'm taking this off list because I want to try to take down the > temperature here a bit. I don't know why you are so angry, but I will > assure you I do know something significant of what I'm talking about. Not > only do I write C code, but I also write C++ code when the need arises, and > I do have legitimate concerns regarding the idea of introducing a separate > C++ API into the engine. I've been involved in this project since 1996 -- I > am a core developer "alum" who has made significant contributions to this > code base (for example, see ext/tidy ) -- these opinions don't come out > of no where. In fact, you aren't even the first person if you want to go > back into the archives to even bring up this argument of more C++ support. > > The things I am talking about matter. Someone has to maintain whatever > APIs you want to introduce, someone has to maintain parity with the C APIs > every time they are changed, and all of that is a lot of work. Maybe that > work is worth the effort, maybe not -- I personally don't believe it is -- > especially when I think this could easily be done outside of core. Either > way, if you want to be successful in an Open Source project you need to > dial back your rhetoric. Not only because it makes the list a toxic place > where volunteers are giving the project their time, but also because it > completely undermines any legitimate argument you might have. I hope you > will take a breath and chill out. This is not useful, helpful, or > appropriate behavior. > > John > >
