On Sat, 31 Aug 2019 at 02:31, Larry Garfield wrote:
> [..]
> Whether editions is the "right" way to balance "don't break 1 million lines
> of 15 year old code" with "this behavior is bad and we all know it" and with
> "this behavior leads to sloppy code that is prone to bugs", I don't know.
>
Some clarifications before I get crucified:
> "editions" (the way I imagine)
I don't want to misrepresent Nikita. His idea of editions might be
completely different.
> If "editions" (the way I imagine) had been introduced prior to PHP 7, we
> might now have a PHP 7 engine that would still
On Sat, 31 Aug 2019 at 03:40, Reindl Harald wrote:
>
>
>
> Am 30.08.19 um 20:56 schrieb Andreas Hennings:
> > In one of -these modules I initially used the ?? null coalesce operator.
> > Then I had to replace all of the instances of ?? with the more verbose
> > old-school code, to make it
(I hope this exchange is not getting too Drupal-specific.
I imagine the same concerns would apply in any project that uses a lot
of 3rd party code, and that is affected by framework versions and
generations of framework ecosystems.)
> Someone running their code on an old and unsupported PHP
On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote:
> On Fri, 30 Aug 2019 at 19:38, Chase Peeler wrote:
> > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings
> > wrote:
> > > The only way to make this possible is to either deny all progress, or
> > > to make a distinction on file level (or
On Fri, 30 Aug 2019 at 19:38, Chase Peeler wrote:
> On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings
> wrote:
> > The only way to make this possible is to either deny all progress, or
> > to make a distinction on file level (or "package level", whatever that
> > means).
> > So, opt-in BC
On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings
wrote:
> I would very much like to see "editions" or "generations".
>
> The only way to make this possible is to either deny all progress, or
> to make a distinction on file level (or "package level", whatever that
> means).
> So, opt-in BC
I would very much like to see "editions" or "generations".
> I do plan to create an RFC on this topic.
I am looking forward to this Proposal from Nikita.
So, at the risk of repeating some ideas that Nikita already mentioned
elsewhere, I am sharing my own thoughts..
## Motivation
In this
On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote:
> This is basically what I have been advocating for a while now already,
> somewhat hidden between all the other noise of the "namespace-scoped
> declares" thread. The model I would like to follow are Rust editions (
>
Hello,
On Thu, 8 Aug 2019 at 22:17, Zeev Suraski wrote:
>
> [... and not in the Sith Lord kind of way.]
>
> Looking at some of the recent (& not so recent) discussions on internals@,
> some of the recent proposals, as well as some of the statements made
> regarding the future direction of the
First of all, Amen to Arvids Godjuks. I think managed to clearly convey the
opinion of a majority of the PHP community.
Some small things I like to add. IMHO the backward-incompatible changes that
are currently discussed aren't about radical changes, but incremental
improvements.
There
On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd wrote:
> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski wrote:
> >
> > My goal is to have two sister languages, with both PHP and P++
> > being equal among equals
>
> PHP internals is already lacking programming resources to do
> everything we want to be
On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
> I think this part is unrealistic from a simple manpower perspective. We
> have something like ~2 full time developers working on PHP. Even if you can
> rally some additional interest
On Fri, Aug 9, 2019 at 3:43 PM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> 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.
>
This isn't splitting the
On Thu, 8 Aug 2019 at 21:17, Zeev Suraski wrote:
>
> My goal is to have two sister languages, with both PHP and P++
> being equal among equals
PHP internals is already lacking programming resources to do
everything we want to be doing.
Maintaining two versions at once would be more work, so
> I'm not sure what you're saying here exactly, but if you are suggesting
> that PHP.future, whatever this future version number is - is going to be a
> strictly typed language, with total disregard for BC /../
I'm suggesting that PHP could stop worrying about "super legacy code which uses
short
Hi Zeev,
pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski 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 > >
>> napisał:
>>
>> > As I understand, in P++ it was
On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk wrote:
> > I think it should also be pointed out that there's nothing stopping
> anyone
> > from forking PHP into a new project as Zeev described and maintain
> feature
> > parity. As I understand, the reason something like this hasn't happened
>
On 09/08/2019 13:07, Zeev Suraski wrote:
It's very, very different.
With this approach, even down the line in 2029, PHP remains PHP. None of
us has a crystal ball to predict the future, but my guess is that WordPress
will stick with PHP, and not move to P++. Based on feedback - Laravel (the
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
> napisał:
>
> > As I understand, in P++ it was planned to drop the legacy code, add new
> > functionality and painlessly implement BC.
>
On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev
wrote:
> As I understand, in P++ it was planned to drop the legacy code,
Correct.
> add new functionality
Correct.
> and painlessly implement BC.
>
Probably correct - but to phrase it more accurately - when we introduce P++
- we won't be
> I think it should also be pointed out that there's nothing stopping anyone
> from forking PHP into a new project as Zeev described and maintain feature
> parity. As I understand, the reason something like this hasn't happened
> already is because it would involve a ton of work and nobody wants
чт, 8 авг. 2019 г. в 22:17, Zeev Suraski :
> [... and not in the Sith Lord kind of way.]
>
> *snip*
>
> Thoughts?
>
> Zeev
>
Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept
messages larger than 3 bytes (#5.2.3)", so re-sending with Zeev's part
sniped out :)
Good day
Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev
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,
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
*alongside patch
Cheers
Joe
On Fri, 9 Aug 2019, 09:33 Kris Craig, wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
>
> > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
> >
> > >
> > >
> > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov
> > wrote:
> > >
> > >> This is
On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
> >
> >
> > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov
> wrote:
> >
> >> This is basically what I have been advocating for a while now already,
> >> somewhat hidden between all the
On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
>
> On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov wrote:
>
>> This is basically what I have been advocating for a while now already,
>> somewhat hidden between all the other noise of the "namespace-scoped
>> declares" thread. The model I
> On 9 Aug 2019, at 12:11, Brent wrote:
>
> Hi Zeev
>
> Happy to see this proposal pop up, it's good to know that the "other side" is
> also open for long-term solutions. I think there needs to be a thorough
> analysis about the pros and cons of the two paths to take: a sister language
>
Hi Zeev
Happy to see this proposal pop up, it's good to know that the "other side" is
also open for long-term solutions. I think there needs to be a thorough
analysis about the pros and cons of the two paths to take: a sister language
vs. Nikita's proposal. To me, a userland developer, both
On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote:
>
>> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote:
>>
>> This is basically what I have been advocating for a while now already,
>> somewhat hidden between all the other noise of the
On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov wrote:
> This is basically what I have been advocating for a while now already,
> somewhat hidden between all the other noise of the "namespace-scoped
> declares" thread. The model I would like to follow are Rust editions (
>
On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote:
>
>> [... and not in the Sith Lord kind of way.]
>>
>> Looking at some of the recent (& not so recent) discussions on internals@
>> ,
>> some of the recent proposals, as well as some of the
On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote:
> [... and not in the Sith Lord kind of way.]
>
> Looking at some of the recent (& not so recent) discussions on internals@,
> some of the recent proposals, as well as some of the statements made
> regarding the future direction of the language
[... and not in the Sith Lord kind of way.]
Looking at some of the recent (& not so recent) discussions on internals@,
some of the recent proposals, as well as some of the statements made
regarding the future direction of the language - makes it fairly clear that
we have a growing sense of
35 matches
Mail list logo
