Hi Zeev, pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski <z...@php.net> napisał:
> > > On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski < > michal.brzuchal...@gmail.com> wrote: > >> Hi Sergey, >> >> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev <ser...@s-panteleev.ru >> > >> napisał: >> >> > As I understand, in P++ it was planned to drop the legacy code, add new >> > functionality and painlessly implement BC. >> > >> > Who wants – migrates the PHP project in P++, who doesn't – 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 – adapts his code for PHP 8/9 with all its BCs, who doesn't – >> > continued to use PHP 7/8. >> > >> >> As I understand editions concept it would be far more easy to interoperate >> 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 break > 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 work > 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 that > unless I'm missing something, maintaining the implementation for all > different editions would be more complicated than having just two dialects. > > 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. But > 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 have > a much stronger bias for features than for downwards compatibility. > > That way you can end up on for eg PHP8 supporting edition=2020 with new >> features which break compatibility but still working with PHP7.4 treated >> perhaps by default as edition=2019 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ł >
