I would say, PHP needs a direction(where're we headed?) than having a split language.
Seriously, the core team have *tons of kudos* from the outside world(even outside of PHP) and i think something called for those serious implementation and i believe everyone(or simply put, the majority) one day would see the need to make many improvements where necessary. P++(Or other name it gets) is another project. On Wed, Aug 14, 2019 at 4:58 PM Chase Peeler <chasepee...@gmail.com> wrote: > On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon <poll...@php.net> wrote: > > > On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans <der...@php.net> wrote: > > > > > https://wiki.php.net/rfc/p-plus-plus > > > > > > To follow up my no vote; What I'm against is splitting the language on > > hard boundaries that never disappear, only widen. I'm also a 'No' on > > Editions, but slightly less of a 'No', and possibly a 'Yes', if those > > editions are clearly intended to fade over time. > > > > -Sara > > > I'd vote "No" if I had a vote. I appreciate Zeev proposing the idea. I've > been as vocal as he has on the short tag issue, and generally fall into the > "avoid BC unless there are overwhelming positives" camp. Maybe I don't have > the complete picture since I don't actually do core development, but I have > been a professional PHP developer for 14 years (Thursday is my 14th > anniversary) and I've been using it for fun/school work for 20 years. From > what I've seen, there isn't near as much contention on BC breaks in general > as a solution like this would require in order to be justified. As someone > mentioned in another thread, the majority of the features discussed (union > types, annotations, enums, etc.) don't require BC breaks at all. Among > things that do require them (both new features and clean up of older > features), I see that most people, myself included, willing to accept them > once they have passed. > > I definitely think it's possible to more PHP forward with lots of new > features, and even cleaning up some old and obsolete parts, without moving > too far in either extreme in terms of BC breaks. I also think that > internals has done a pretty good job of that up to this point, and have no > doubt they will continue to do so. > > I don't know if it was just a coincidence in timing, but it feels to me > like this proposal was spurred, at least in part, by the discussions over > short tags. If so, I definitely think that it is an overreaction. I also > think the discussions on short tags show why even taking this proposed path > wouldn't solve anything in the long run. The discussion over short tags > have got pretty heated at times, but it seems to me that it is mainly > because both sides are just repeating their talking points without > discussing or answering the points made by the other side. I think that is > partly due to the discussion medium, and partly due to the diversity of the > participants. Without immediate feedback in a manner you expect, it's hard > to tell if the point you just typed out over 5 paragraphs actually made > sense to others that will read it. Bottom line, though, is that there will > be contentious debates about topics no matter what. You might be able to > avoid the debate on whether or not to require strict typing in P++, but > you've still got to decide on which types you're going to support. Strict > typing might never again need to be discussed in legacy PHP, but, there > will always be discussions about some of the more controversial ways that > types are juggled. > > There might be a time in the future where I do feel like a proposal like > this is justified or even needed. I just don't feel we are at that point > right now, nor do I think we are headed towards it. > > -- > Chase Peeler > chasepee...@gmail.com >
