> On Oct 11, 2022, at 8:24 AM, Christian Schneider <cschn...@cschneid.com> > wrote: > > We seem to have two different views on experimental feature here: You are > saying they could get removed again while others stated it is for stuff which > will definitely end up in stable when the next major release is done. > > IMHO there needs to be a consensus about this before we can continue the > discussion, otherwise we will go around in circles.
True. In my view experimental would allow to features to be tried that might get removed, but others may not want that. However, I think it is really a moot point because of RFC voting. If enough people felt it might get removed they would vote against it. And if after something was experimental if enough people felt it should be removed they would vote to do so. So each individual RFC as well as voting addresses that concern. > That's another thing where we need to find an agreement first: Are we talking > new, isolated functions or are we possibly also talking about core new > language features (i.e. new syntax / semantics)? > > The work for maintenance by core developers could be much higher if it is not > limited to new functions. > This is IMHO an important aspect as we do not want to make life even harder > for the core team. Again, each individual RFC and voting address that concern. If an experimental RFC would resolve it "too much" maintenance by core developers then it would get voted down. A 2/3rd bar for success is not a low bar, especially in a community with so many divergent opinions. > Hot take: If it is only about new functions then we don't need anything in > the core, just create an \Experimental package with poyfills and you're done > ;-) My hot take: Having the entire PHP community made aware of a given experimental function — including all the blog posts that would be written about it — is != to an individual developer creating an \Experimental namespace and writing their own blog post about it. >> Not all potentially useful functions can reasonably be implemented in >> userland PHP. > > ... but almost all of them can. See reply in prior paragraph. > I'd go as far as saying that while emulating json_validate() using > json_decode() is slower and uses more memory it still is a valid polyfill. > It is IMHO easy enough to develop with a higher memory limit and performance > is not that critical for development either. For json_validate() people have *already* been using a polyfill, and it was found sorely lacking for memory-use reasons. So a reason for making it experimental would be to see if the proposed signature was sufficient for mainstream needs. Oh, and a higher memory limit is not always a viable solution. > And unless you want to ship experimental code to production (which you > shouldn't) you will have to wait for the next major PHP release anyway. Not all "production" code is equal. My blog != Wikipedia, for example. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
