On Fri, Aug 9, 2019 at 3:02 AM Joe Watkins <krak...@php.net> wrote: > Morning all, > > First, I want to say that I don't think the polarisation claimed to be > occurring is actually occurring. The vast majority of internals voters > appear to judge each RFC on it's own merit, while some of them give more > weight to retaining bc than others and that effects their vote, they didn't > decide how they are going to vote before reading the proposal. There are > some very vocal internals mailing list contributors that may give the > impression that there is much more dissent, from many more people, or much > more controversy than there actually is. A thread is not controversial if > some high percentage of the correspondence is from one or two person, it's > spammy. > > I agree. For the most part, the issue isn't with BC breaks in general. Short tags has become very contentious because those against removing them (like myself) see a HUGE downside to removing them and little, if any, upside. That's where the contention is coming from. I think some of the people on the pro-removal side have framed it as if those against removal were against BC breaks in general. Others then come along and scan through the thread and think the issue is a "BC good" vs "BC bad" one.
I'm one of the people that has been pretty vocal against removing short tags. At this point, I'm not a huge fan of this proposal. I can't point to anything specific - it just doesn't feel right. I think one of the reasons, though, is because I'm not against BC breaks in general. When it comes to the proposal being made, that we develop ++ "overnight" > and "get everything right the first time" ... I'm not sure how serious > these statements are, on their face, they don't make much sense, although > they may just be the result of extreme optimism rather than non-thinking. > > As developers I think we all know that you'll never get anything right the first time. No matter how much thought and effort is put in ++, there are things that are going to be outdated, abused, or simply unnecessary further down the road. Then we'll be back where we started when it comes to BC breaks. > When it comes to the idea of editions, this would appear to have actual > merit, there's some overlap with the ++ idea, but they are distinct, and > editions and a more forward looking sustainable solution to the problems we > are facing and will continue to face. > > Now I just want to point out the subtle difference between editions, and > versions of a language (whatever it's name) ... > > Should we take up proposal one, and [magically] develop an overnight > language, we would have to version subsequent releases as per our > versioning guidelines, they would be subject to the same bc concerns that > versions of PHP are today. We would find eventually ourselves in exactly > the same position with ++ as we are with PHP. > > Should we take up proposal two, and start to develop opt-in editions to be > released alongside minor releases, these editions do not need to have the > same BC concerns as regular PHP. Should we make a horrible mistake in some > edition, we don't need to take 10 years to fix it, we may even fix it in > the very next edition. > > Cheers > Joe > > > > > > > > On Fri, 9 Aug 2019 at 01:53, Mark Randall <mar...@gmail.com> wrote: > > > On 09/08/2019 00:08, Zeev Suraski wrote: > > > 2. Different people have different preferences. There's a reason that > > not > > > everyone is using the same language, or have the same mobile phone or > the > > > same car. Something it's not 'forward' or 'backwards' - it's about > > > 'different'. Is C++ better than C? Many would argue that it is, while > > > others will argue that it's not. Both can be correct, it's ultimately > > not > > > only a matter of objective truths, but also subjective perceptions, > > > preferences and the tasks at hand. > > > > I'd say C++ gives you extra tools to do the job you want to do, and to > > do them quicker, and safer (std::string vs char[]). > > > > > 3. Putting your apparent personal bias against backwards compatibility > > > aside - if P++ goes in the directions you're hoping for - towards > giving > > > you the goodies on your wish list, why would you care if PHP still > > existed > > > without these new changes/features? > > > > I'm not inherently biased against BC. But it doesn't exist in isolation, > > in my mind I have to weigh the benefits of BC with the benefits that > > breaking BC could bring. IMO, long term, the former is greatly > > outweighed by the latter. > > > > The thing is, I don't see PHP diverging in the way you suggest. I > > suspect it would end up being versioned within the same application, > > even though I suspect that would be much harder to pull off, it may end > > up that it's not actually possible. > > > > I was trying to think of something which could easily break if passed > > between two versions, and something which immediately came to mind was > > union types and reflection, a method which returned one string would > > need to return an array, or just the first, and so on. > > > > A "separate" version would certainly be easier. The ability to rip out > > everything which wasn't kept would no doubt simplify a lot of things, > > but I agree with Nikita's point that it only kicks things down the line > > until the next break. > > > > I think side-by-side engine versions are likely going to be the end > > result if it's possible. > > > > My heart says "clean break" my head says "side by side". > > > > Mark Randall > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- Chase Peeler chasepee...@gmail.com
