Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106488
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
 <CAJHtznzFSP4u7HggZPmyi27ejUie6x+kUytvTCd+WTpsKwFwag@mail.gmail.com>
 <CAF+90c8Ws-Ap2Ztw87gBS3bn_dKq+c+eNtAL90SCgqWhwsJCwA@mail.gmail.com>
 <CAKOpQSyWcge-6D9bu+bsJx=JdJ45MJd4KiqAuXzjQhTpWP4q0Q@mail.gmail.com>
 <8a95f23e-4145-46ee-ba49-6c24c32c8243@Spark> <CABdc3WpkBvDY0c4ULsbsOoA8begqqYn-j-R3f5RkLvCt-iSYdw@mail.gmail.com>
 <CAJHtznzJ0xv-_h4duFot-LSzQA=uJ=WOmzzKXSSUvZ7Jxgf5jw@mail.gmail.com>
In-Reply-To: <CAJHtznzJ0xv-_h4duFot-LSzQA=uJ=WOmzzKXSSUvZ7Jxgf5jw@mail.gmail.com>
Date: Fri, 9 Aug 2019 14:43:22 +0200
Message-ID: <CABdc3WqaZD1Fb3i0FAuY-iuUOOBohwDd6FBf=pAXKqA9BR7Pkg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Sergey Panteleev <sergey@s-panteleev.ru>, Nikita Popov <nikita.ppv@gmail.com>, 
	Kris Craig <kris.craig@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d1f14d058fae85a9"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--000000000000d1f14d058fae85a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Zeev,

pt., 9 sie 2019, 14:23 u=C5=BCytkownik Zeev Suraski <zeev@php.net> napisa=
=C5=82:

>
>
> On Fri, Aug 9, 2019 at 11:15 AM Micha=C5=82 Brzuchalski <
> michal.brzuchalski@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> pt., 9 sie 2019, 09:40 u=C5=BCytkownik Sergey Panteleev <sergey@s-pantel=
eev.ru
>> >
>> napisa=C5=82:
>>
>> > As I understand, in P++ it was planned to drop the legacy code, add ne=
w
>> > functionality and painlessly implement BC.
>> >
>> > Who wants =E2=80=93 migrates the PHP project in P++, who doesn't =E2=
=80=93 continues to
>> > use PHP.
>> >
>> > New projects, for example, will use P++ already.
>> >
>> > Well, how is this different from the new version of PHP (e.g. PHP 9)?
>> >
>> > Who wants =E2=80=93 adapts his code for PHP 8/9 with all its BCs, who =
doesn't =E2=80=93
>> > continued to use PHP 7/8.
>> >
>>
>> As I understand editions concept it would be far more easy to interopera=
te
>> with old edition written library than in separate languages like PHP and
>> P++. If new edition introduce syntax breaking change it would be still
>> possible to to interoperate with old code in old edition and work on a
>> project based on new edition.
>>
>
> If we intend to break syntax frequently, then yes.  But this is poor
> language design.
> If we take a couple of years to focus on the fundamentals of what folks
> find objectionable about PHP today, and introduce P++ with solutions to
> these issues - there's no reason that every new version continues to brea=
k
> compatibility - certainly not in a substantial manner.  We need to focus =
on
> the painful changes at the first stage, when P++ is introduced - while
> keeping other elements - ones which are incremental but do not introduce
> compatibility breaks - to a later time (if we don't have the
> developer-power to deliver them).
>

I've got an impression that you're the only one who sees a good direction
in splitting the language in two different dialects and am not sure about
sincere intentions.
I may be wrong about that but I read this as a way to get evolutionary camp
focus on own dialect and leave PHP in peace. But I think their interests
are in language evolution and not in writing own language.


> If we let ourselves off the hook, and do these breakages in stages -
> editions are basically a workaround.  Yes, editions would allow you to wo=
rk
> around the fact that your code breaks every time you upgrade - but at a
> fundamental level, people are still wasting their time writing and
> rewriting and then rewriting once more the same code.  Not to mention tha=
t
> unless I'm missing something, maintaining the implementation for all
> different editions would be more complicated than having just two dialect=
s.
>
> Now, it doesn't come to say that P++ will never be able to break
> compatibility.  We also break compatibility in PHP, in major versions.  B=
ut
> it does mean that something along the lines of moving from dynamic to
> static, can't happen further down the line.  Changing operator or
> type-conversion behavior - has to happen now and not further down the
> line.  Features such as union types and others - can happen at a later
> stage.  I don't think there's a need for editions for that purpose, the
> versions we have are sufficiently granular.  Even more so since this will
> likely effect P++ more frequently than PHP - a crowd which appears to hav=
e
> a much stronger bias for features than for downwards compatibility.
>
> That way you can end up on for eg PHP8 supporting edition=3D2020 with new
>> features which break compatibility but still working with PHP7.4 treated
>> perhaps by default as edition=3D2019 in future versions.
>>
>
> I could be wrong, but I don't think that even Nikita thinks we'd have a
> new edition every year.
>

That's just an example.

BR,
Micha=C5=82

>

--000000000000d1f14d058fae85a9--