Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124958 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 29BE81A00B7 for ; Thu, 15 Aug 2024 21:12:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1723756466; bh=HP3e17ZVZ1vPma7IqGs0s/ulKpTJQ+tAqWKLcQMDVZ4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZVlD/imNFFGvR2FNPhzxFMRMT1X4zmKZxi6NjHVCjwNmFCkLMLzKgWiIhDbvdJDOi yhO/NwUsuBBQPmfOVOuLGcFCDBQYFMC3NBleD0rlGoKJls4YbApuKTOJ08talU6wgS /WPGEuE182Hn3rRDhX6iMtu1E5aQb11GKlsFNDj4KukMQsEajkkNSiSJ2cy/d1YrSN cXiY3O5PeDvgBKuWS+Yrc6j4OmPh/T19GWmBfsmldYFBzLOOPVhHCJwtgLdWEv9dnq 5NyrO+WmDKqt/bqtQ8wkeojHYEpchyqlP9IcD2NcGuBL4eEQQwvFt1n9P0lV6PcxTb zBiohKxuzNLvg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1E85A18005B for ; Thu, 15 Aug 2024 21:14:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 15 Aug 2024 21:14:18 +0000 (UTC) Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-4f5153a3a73so453955e0c.2 for ; Thu, 15 Aug 2024 14:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723756351; x=1724361151; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XmLa5KVDv60RD+WJCwYdIt7KPDHt/kZBKtCh+7iKr1Y=; b=ArfM45vdQSR/mi+vw/7mdJYXqjPttUFjCa7TYEQT2c6+BYfQnKg2lUuHTFJN212ikB eHHZoRFKVFcWjp1jZ1Fk4lsPvfAJbnuCzrxEg9M/gyfHS58xy1rHC+41d0rUZIZZQqoj q5X4kKunC0OYkBG0QH4jf7AugxgD9v1gc/5mWBitz0YoWnagOsmC3TsfoEdso5YVB2bv HbSLcJQcha/nEkv9ttKRpXaURA98cwS+pr709MhPlem6Rq3rh0EUytr0hSD6SRGe1Y3G 8BstrR6SWZxmr1iBFGIp7HrurzxRJqYhQ7SKW9+ZdYgc6NLIDzdRXDSjVmWtNn0i8lwF naWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723756351; x=1724361151; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XmLa5KVDv60RD+WJCwYdIt7KPDHt/kZBKtCh+7iKr1Y=; b=suvAXgl5cGlviE4ebHkZ894VGlwQAZbX1hFNyJU36VlZWJF2MZGI881myaVxjHIRIj qUHR7AkmRgHlSAV0NZDWtl6d2DjHxNCpNdjuft5CLFUHRuZDGJT7Ug7d8zAyKBQJfFNU BGxSqnoxNhCK9BxCJO2AP0PXyjm7/dQS9Wmi6yIxdr7IYIxRQ/MZIXr42QVDaE+QkYMf HUp+lWgnsWtsYpOfScXuTswQmTMKMihdMkXG9gyDrqXWp9CAuGqWV0DzBzXoXTIo0JrZ YWoHzEBDAaNSXSMTG1mRC/GQ57t/xoy+U8Y7vJalv4k5atEdEe4le6N6AR44O1+8LfgU 63Og== X-Forwarded-Encrypted: i=1; AJvYcCVU0XXLD9To56IkBJ/O9XS3WR97YOLDimo65n/YSxDYkxPu5MouIKz8qFyt9D4VOVyAxBlwENd/5Q+7JCfEu/ajy1WH9kMJFQ== X-Gm-Message-State: AOJu0YzpEt66B9jhw/OdHtXM4X8alea/rxqDh5bJcJ7pwlFZBUKoecUW xjerxahBe4vDxe85klLvCGAf8wXb40Ec/xnd3tgFNwcMMVhVpedPdoVjjwhF57hbaydq6b1FauP kb7fbTi8cWMcW4omYrM74aGoXNEVKCoe1 X-Google-Smtp-Source: AGHT+IFRmPLczYpBVt8W1rW+uTTO3aOW3hAD7/NSOi3Xmub4jCjJUOpf0tbMp2GB9vDeesz6EKwyoZJbXJDQVk5E3RA= X-Received: by 2002:a05:6122:d8b:b0:4f2:ea44:fd14 with SMTP id 71dfb90a1353d-4fc6c5a3df5mr1388415e0c.2.1723756351190; Thu, 15 Aug 2024 14:12:31 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 15 Aug 2024 15:12:19 -0600 Message-ID: Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API To: Bilge Cc: Derick Rethans , PHP internals , John Coggeshall , Mike Schinkel , Pascal Chevrel , Levi Morrison , Arvids Godjuks Content-Type: multipart/alternative; boundary="000000000000fe0144061fbf4c09" From: lnearwaju@gmail.com (Lanre) --000000000000fe0144061fbf4c09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM John Coggeshall 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 of= f > 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 yo= u > 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 wi= th > 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 largel= y > a historic issue, as I'd bet most of us are C devs first and PHP for bett= er > 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 oth= er > people built. If you are the only person who is able to maintain somet= hing > 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 h= ave 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 what= ever > reason, and 6 mos later disappeared leaving the project holding the ba= g. > 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 prob= ably > move on and leave and someone else is going to maintain your code... o= r > 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 maint= ain > 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-te= rm > 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 th= em > 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... n= ow 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 buttin= g 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 plac= e 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 propo= sal 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 communit= y. > 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 us= e > 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 wrote: > > Hi John, > > Thanks for reaching out to me directly=E2=80=94I really appreciate it. I= =E2=80=99m a C++ > developer and don't work with PHP professionally; it=E2=80=99s 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=E2=80=99t just that certain implementations are repeatedly = being > recreated; it=E2=80=99s also that this repetition breaks portability for = C++ > extensions. You can't use standard library containers without ensuring yo= ur > class or struct adheres to specific rules. This leaves you with two optio= ns: > > > 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 doe= s > this, it=E2=80=99s undefined behavior. > > Option A works well, but I have to do this for each extension I write. Th= e > problem is that even though these new subclasses in each extension are > practically identical, they=E2=80=99re not compatible with each other wit= hout > linking all the extensions or a common object file that defines this. Thi= s > introduces a dependency that isn=E2=80=99t Zend/PHP, which is why I don= =E2=80=99t bother > shipping some of them. > > You seemed to assume I wasn=E2=80=99t willing to maintain my code=E2=80= =94isn=E2=80=99t that a > given? Or do you think I believe code just works without maintenance? You= r > point about someone needing to maintain APIs and ensure parity with C API= s > 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=E2=80=99s not true= . If it=E2=80=99s > 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=E2=80=99m paid $300k a year to do so. You lack the experienc= e to > confidently say, "this could easily be done outside of core"=E2=80=94you= =E2=80=99re > essentially guessing. How many C++ extensions have you written? How many > times have you encountered and solved this issue? > > I=E2=80=99m volunteering for this, with only a day left of my week off, w= hich > means I probably won=E2=80=99t be pursuing the RFC until the next opportu= nity I > get. So, thanks for that. > > Lanre > > On Thu, Aug 15, 2024 at 12:13=E2=80=AFPM John Coggeshall > 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, a= nd > I do have legitimate concerns regarding the idea of introducing a separat= e > 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 API= s > 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 > > --000000000000fe0144061fbf4c09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John reached out to me directly, but i think he raise= d some valid points that I should address here, so here it is:


On Thu, Aug 15, 2024 at 1:56=E2=80=AFPM John= Coggeshall <john@coggeshall.org<= /a>> wrote:
<= div>Lanre,

I think you're expectations are probably unrea= listic if you expected to drop a PR in a week to add C++ support as you des= cribe, and expect it to be immediately accepted (which is what I'm taki= ng from your "I had a week off to do this" comment).
=C2=A0
Correct me if i'm wrong but aren't RFCs= usually for changes that somehow affect userland or the API? This does nei= ther and is fairly simple to implement so I assumed this thread would be mo= re about implementation details and what branch to merge this to. It isn= 9;t unrealistic for me, but to each their own.=C2=A0
=C2=A0
=
Also, I honestly co= uldn't care less how much money you make -- it doesn't excuse your = behavior on the list.=C2=A0
=C2=A0
Never s= aid 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.=C2=A0 I get paid a lot to do wha= t I'm offering to do for free.

I shouldn't have to privately messag= e 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 o= ff you'll just be removed eventually if you keep it up. That's not = a threat, it's just what eventually happens.
=C2= =A0
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 e= ntirely honest I really don't have the time to walk through all of it w= ith you, but I'll do my best to give you some insights that will help y= ou 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= 9;s largely a historic issue, as I'd bet most of us are C devs first an= d PHP for better or worse was written in C. That's not to say you'r= e 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?
=C2=A0

I'm not entirely clear what= you mean when you say handling this at the extension level is "breaki= ng portability" -- in what sense do you mean? I'm also a little co= nfused by your statement "these new subclasses in each extension"= ... subclasses of what parent class?
=C2=A0
zval parent class.=C2=A0


Either way, anytime people start talking abo= ut 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 destru= ctor, comparison operators as well as common methods, which will all be beh= ind a C++ macro. Those are necessary changes
=C2=A0
  • It matters to this p= roject, and every open source project, that there is a confidence that peop= le 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 s= ome code no one else could maintain for whatever reason, and 6 mos later di= sappeared leaving the project holding the bag. It's not that I don'= t think you understand code requires maintenance -- it's that you don&#= 39;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 co= de goes unmaintained and the whole project suffers.
What are you basing this on? You just read my proposal and instea= d of attacking the points I made, you are making baseless accusations. I do= n't get paid for this, so obviously I will only maintain it for as long= as=C2=A0it=C2=A0interests=C2=A0me, which is completely fair. PHP Foundatio= n exists and accepts donations for what exactly if not to pay devs to maint= ain php-src?=C2=A0
<= ul>
  • One of the ways to get past the issue above is to create confid= ence around your idea that there is enough talent in the community to maint= ain 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 lon= g-term maint of the changes as necessary. To wit;=C2=A0
    • Why do you assume that no one else is capable of maintaining = this?=C2=A0
    • =
      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. M= any 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=C2=A0zval=C2=A0 (allocated separately), or are = you proposing we start allocating=C2=A0zval=C2=A0s on an objec= t creation?

    Yes, = when implemented as an extension, it has to be a subclass of zval. If imple= mented in core though, it would be added directly to zval (under C++ guards= ).

    • If we now have an object that represents a=C2=A0zv= al=C2=A0, does that mean this object has methods that reflect the C = function calls? e.g. is there a=C2=A0print=C2=A0 method that m= aps to=C2=A0zend_print_zval=C2=A0?
    • C doesn't have methods. And maybe? That's part of t= he implementation details I was hoping do discuss.=C2=A0
      • If you are now in= troducing a whole new way to "print a zval" (e.g.=C2=A0zend= _print_zval(myZval)=C2=A0 and=C2=A0myZval->print()= =C2=A0, what is the justification for a whole new API?
      • =
    A print method would fall under 'common methods&= #39; not a big deal, but it would improve readability in C++ code.=C2=A0
        • Who is going to maintain it? Right now we already have to worry abou= t 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 h= opefully someone else. Is there a different way it's supposed to go?=C2= =A0=C2=A0
      • There won't always been a clear translation of=C2=A0= zend_print_eval=C2=A0 to=C2=A0print()=C2=A0, isn&= #39;t introducing a new OO API on top of the procedural one going to butt h= eads on some points? Who wins?
    How would it butt heads if it doesn't even work in C? Who woul= d be butting heads exactly? I think i'm missing your point here.=C2=A0<= /div>
        • =
        • What about the values inside of=C2=A0zval=C2=A0, do y= ou propose proxying access to those from this class? (e.g.=C2=A0myZva= l->v=C2=A0)
    = Nah, I propose myZval->String() for when the zval is a string (which sho= uld be determined by myZval->IsString()) and myZval->AsString() to pr= oxy `convert_to_string`. That's a valid question.
      • If it's literall= y a class wrapper around a=C2=A0zval=C2=A0 for linking or what= ever reasons to avoid the=C2=A0zend_print_zval=C2=A0 vs.=C2=A0= print=C2=A0issues, what policies, defensive coding techniques,= etc. do we need in place so the next guy 2 years from now doesn't thin= k it's a good idea to add a=C2=A0print=C2=A0 method becaus= e 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=C2=A0zend_print_zval.(other than more code we have to maintain,= which again applies to all changes).
      • Is this proposal literally limited t= o=C2=A0zval=C2=A0 or are you suggesting a collection of classe= s around various engine structs? If the proposal were to be adopted to acce= pt your=C2=A0zval=C2=A0 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 th= e community. The best way you can do that is a well thought out RFC that sh= ows the community you have put in the necessary time and consideration to m= aking such a fundamental addition to the engine.
    =C2= =A0
    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 r= easons for saying no to my proposal, not just "someone will have to ma= intain it" and "C++ is obsolete so this is pointless". It is= just as ridiculous as expecting me to whole RFC simply to introduce an ide= a. Even the RFC guide requires a discussion first, unless I am missing some= thing.
    =C2=A0
    No one, including me, is looking to make it unnecessarily difficu= lt to use C++ to write extensions,

    Ar= e you sure about that?=C2=A0
    =C2=A0
    but the difficulty that exists today is bec= ause trying to come up with smart solutions to questions such as above is h= ard.

    Says who?
    =C2=A0
    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.
    =C2= =A0

    Joh= n

    On Aug 15 2024, at 2:50 pm, Lanre <lnearwaju@gmail.com> wrote:
    Hi John,

    Thanks for reaching out = to me directly=E2=80=94I really appreciate it. I=E2=80=99m a C++ developer = and don't work with PHP professionally; it=E2=80=99s something I do for= personal projects and scripts. I had a week off and decided to create some= thing that could make life easier for C++ developers like myself when writi= ng extensions.

    The issue isn=E2=80=99t just that certain impl= ementations are repeatedly being recreated; it=E2=80=99s also that this rep= etition breaks portability for C++ extensions. You can't use standard l= ibrary containers without ensuring your class or struct adheres to specific= rules. This leaves you with two options:

    1. Write a wra= pper class that extends=C2=A0zval=C2=A0to make it compatible (= which is my usual approach).
    2. Override global operators f= or=C2=A0zval, which is problematic as you still won't have= a constructor or destructor. If another extension does this, it=E2=80=99s = undefined behavior.
    Option A works well, but I have to = do this for each extension I write. The problem is that even though these n= ew subclasses in each extension are practically identical, they=E2=80=99re = not compatible with each other without linking all the extensions or a comm= on object file that defines this. This introduces a dependency that isn=E2= =80=99t Zend/PHP, which is why I don=E2=80=99t bother shipping some of them= .

    You seemed to assume I wasn=E2=80=99t willing to maintain m= y code=E2=80=94isn=E2=80=99t that a given? Or do you think I believe code j= ust works without maintenance? Your point about someone needing to maintain= APIs and ensure parity with C APIs applies to any change made to the engin= e, so why keep bringing it up?

    You said this could be done ou= tside the core, but that=E2=80=99s not true. If it=E2=80=99s done outside, = it will be incompatible with other external implementations. This is part o= f my frustration. You write C++ "when the need arises"; meanwhile= , I=E2=80=99m paid $300k a year to do so. You lack the experience to confid= ently say, "this could easily be done outside of core"=E2=80=94yo= u=E2=80=99re essentially guessing. How many C++ extensions have you written= ? How many times have you encountered and solved this issue?

    = I=E2=80=99m volunteering for this, with only a day left of my week off, whi= ch means I probably won=E2=80=99t be pursuing the RFC until the next opport= unity I get. So, thanks for that.

    Lanre

    On Thu, Aug 15, 2024 at= 12:13=E2=80=AFPM John Coggeshall <john@coggeshall.or= g> wrote:
    Lanre,

    I'm t= aking 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 k= now something significant of what I'm talking about. Not only do I writ= e C code, but I also write C++ code when the need arises, and I do have leg= itimate 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 cor= e developer "alum" who has made significant contributions to this= code base (for example, see=C2=A0ext/tidy=C2=A0) -- these opi= nions don't come out of no where. In fact, you aren't even the firs= t person if you want to go back into the archives to even bring up this arg= ument of more C++ support.

    The things I am talking about matt= er. Someone has to maintain whatever APIs you want to introduce, someone ha= s to maintain parity with the C APIs every time they are changed, and all o= f 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 becau= se it makes the list a toxic place where volunteers are giving the project = their time, but also because it completely undermines any legitimate argume= nt you might have. I hope you will take a breath and chill out. This is not= useful, helpful, or appropriate behavior.

    John
    --000000000000fe0144061fbf4c09--