Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106469
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>
In-Reply-To: <5d4cb5e3.1c69fb81.31333.3db0SMTPIN_ADDED_MISSING@mx.google.com>
Date: Fri, 9 Aug 2019 09:01:50 +0200
Message-ID: <CAOwTYAsxnuxugfN2eZmTjUecfjgZvomr--t0gA==o-iEt2n2kA@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004b05b9058fa9c082"
Subject: Re: [PHP-DEV] Re: Bringing Peace to the Galaxy
From: krakjoe@php.net (Joe Watkins)

--0000000000004b05b9058fa9c082
Content-Type: text/plain; charset="UTF-8"

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
>
>

--0000000000004b05b9058fa9c082--