Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106471
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=T6UP78xu0eDaLcOawI9IeCCn3SkQ+mXtIkWb4GIsOgSVPylcr0r+fWctLEF7bJ
	qY1+svwL+T9vXj1Ma9OUF46KBCk7zSXwPXJACNlgf3SeOtYz5lws4QcpCInZ7UkF
	NAJWbkp2/seGwri2xbT9xXAt8MlPoa3u9Ttpz5lQ92Ics=;
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 10:19:54 +0300
Message-ID: <CAJHtznwn3bjAtpKq82BmzjUeOupME85=8istFovNSAbqVEO_8A@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="000000000000dff8c0058faa008c"
Subject: Re: [PHP-DEV] Re: Bringing Peace to the Galaxy
From: zeev@php.net (Zeev Suraski)

--000000000000dff8c0058faa008c
Content-Type: text/plain; charset="UTF-8"

Joe,

Top posting on purpose because you seem to focus on the 'overnight' element
while not understanding quite what I meant (I'll take the blame for that) -
and therefore deriving irrelevant conclusions.

When I'm saying "overnight", I mean from the end users' perspective.  In
the same way that C++ didn't gradually roll out its features as a slow
steady stream - but rather, was made available one day with a lot of new
capabilities - essentially a new language - that would be the same idea
here.

It doesn't mean it'll happen on August 10th, at least not 2019.  It may
take 2 or 3 years to complete.  But once we have it ready - it'll be made
available in one installment, with all the major issues that are on the top
list of folks handled.  That is, in contrast to breaking some stuff, and
then breaking some more a few years down the line.

Zeev

On Fri, Aug 9, 2019 at 10: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.
>
> 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
> >
> >
>

--000000000000dff8c0058faa008c--