Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106502
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <5d4ca16b.1c69fb81.bcb4a.9e51SMTPIN_ADDED_MISSING@mx.google.com>
 <CAJHtznwBiMBV1SJDV4oPdA0sUj=YnjvwpY0N6RF+YC2HH00AAw@mail.gmail.com>
 <5d4cb5e3.1c69fb81.31333.3db0SMTPIN_ADDED_MISSING@mx.google.com> <CAOwTYAsxnuxugfN2eZmTjUecfjgZvomr--t0gA==o-iEt2n2kA@mail.gmail.com>
In-Reply-To: <CAOwTYAsxnuxugfN2eZmTjUecfjgZvomr--t0gA==o-iEt2n2kA@mail.gmail.com>
Date: Fri, 9 Aug 2019 14:44:39 -0400
Message-ID: <CAPKYkKxi-fxHsQ5Ub=mPmQ4jO-nGyV7Xi93JFV_n3C0pYdeU6w@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: Mark Randall <markyr@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c5cd9e058fb3910c"
Subject: Re: [PHP-DEV] Re: Bringing Peace to the Galaxy
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000c5cd9e058fb3910c
Content-Type: text/plain; charset="UTF-8"

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

--000000000000c5cd9e058fb3910c--