Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

  106469
August 9, 2019 07:01 krakjoe@php.net (Joe Watkins)
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.

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.

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 <markyr@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 > >
  106502
August 9, 2019 18:44 chasepeeler@gmail.com (Chase Peeler)
On Fri, Aug 9, 2019 at 3:02 AM Joe Watkins <krakjoe@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 <markyr@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 chasepeeler@gmail.com