Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106834
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAF+90c-+ewSj2oTASZMrENuaDRA3ys=LdAwwjjbVjA2v7Es+Kg@mail.gmail.com>
 <CAJHtznzx6u7h2dYtAMTtgpzGnVYgYRA0JvJ5p=4-koor-Wdnbw@mail.gmail.com>
 <33b4068a-3b32-4904-a033-4ff3f28e1161@aegir.sexy> <1EDD1FE6-9AB8-4CDF-8EE4-416C18390725@gmail.com>
 <bb322cbd-c283-ea77-8889-619f3927854c@aegir.sexy> <CAJHtznxf=FAL_aWz1eL5fS1xQ1NRKae+4UqE7pVSn-9cG7ScpA@mail.gmail.com>
 <94054653-020b-78bb-9208-d0533b85be72@aegir.sexy> <A5670EC4-30BB-4E21-AD0D-71EF1E56F2F0@cschneid.com>
 <ac609c51-407b-9910-9016-64c16f94598d@gmail.com> <CAESVnVqXoUJYZjT2P_AhqEo8J40+Wj7tXfY3zkd4g+K4Kw+9ZA@mail.gmail.com>
In-Reply-To: <CAESVnVqXoUJYZjT2P_AhqEo8J40+Wj7tXfY3zkd4g+K4Kw+9ZA@mail.gmail.com>
Date: Mon, 2 Sep 2019 20:02:44 +0200
Message-ID: <CAL0xaBGdV_5nUSoSAns2OFx4x8EWqycJviZNkchOZvrdS00mHg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Aegir Leet <aegir@aegir.sexy>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eea74e059195c84f"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000eea74e059195c84f
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 2, 2019, 19:02 Sara Golemon <pollita@php.net> wrote:

> On Thu, Aug 29, 2019 at 2:29 PM Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
> > >> I knew it worked, but I always considered this to basically be
> > >> the PHP equivalent of undefined behavior in C. And I don't think
> anyone
> >
> > It's not. It's very well defined behavior, that is not going to break -
> > unless it is broken intentionally in a zeal for adding more strictness
> > for the sake of strictness. So, another thing to learn. I love learning
> > new things, and love helping others do so!
> >
> > It is well defined. It's also, in my PERSONAL opinion, gross AF.  That
> doesn't make me right or better or anything other than opinionated.
>
> Other opinions:
> * I'd quite like PHP to be a little less gross in places like this.
> * I think Nikita's hitlist here is a step in the right direction,
> however...
> * I DON'T think the cost to BC is justified in all cases. For example, an
> exception for read of undefined vars is traumatic BC.
> * I think declare(strict_types=1); already solved a very similar problem
> and could easily be applied to future issue like this.
>
> So how about we suck it up, put on our big girl panties, and just embrace
> declares (including namespace scoped declares and/or a modern version of
> .htaccess)
>
> -Sara
>

Hi Sara,

I do agree with most of it, especially about the big girl panties part, but
I do disagree with the declares part.
There should be one general use declare I think - declare(strict=1) - and
it should be the mode where PHP is going as a language into the future
and contain the strict types, stricter operators, the full suite of error
level rework (include everything Nikita has added in this RFC and probably
work on next iteration later),
have other stuff cleaned up too?

Here's the rationale:

Projects these days tend to be sizeable and growing all the time - they
require strictness to be maintainable by multiple people. We have seen a
rise of more strict and less feature-rich languages that are becoming a day
to day instruments for many things (Go anyone?) and the average skill of
the workforce has gone down somewhat a lot these past 10-15 years. So
tightening the screws is somewhat a necessity these days and leaving PHP
with its idiosyncrasies as it is right now in the weak mode is not a good
idea for the future. People have changed, development has changed, tools
have changed, how we write PHP code has changed DRAMATICALLY and PHP
community has been keeping up with past 5 years of PHP development faster
than PHP is evolving itself. I mean take NodeJS and JavaScript - their dev
cycles are running at breakneck speeds and you basically have to re-learn
things on a yearly basis to stay up to date. But it is a mess because the
ecosystem is young.
In PHP our ecosystem is mature, we have very good libraries and frameworks
that have clear release cycles and have reasonable upgrade paths and do
keep up with PHP itself - the adoption rates are probably at their highest
right now.
I say it's time to capitalize on this momentum and settle into a rhythm of
improving the language and its ecosystem by streamlining and building for
the next 20 years of it's lifecycle. With JIT coming up, a lot of things
will start to become possible and there are going to be a lot of things
that you want to make more explicit in the code to make sure JIT can take
advantage of and optimise.

So, back to the strict mode idea: why not introduce that mode in PHP 8
(fold strict_types into it and have a depreciation notice for strict_types
so people switch to declare(strict_mode=1) ), continue developing stuff for
that strict mode during the life of 8 versions and state everywhere that
this is preferred and future proof mode, in PHP 9 starts deprecating things
in non-strict mode pushing people to fix things like undefined variables,
index access notices, have more strict operators. An in PHP 10 basically
sunset the bad parts of the non-strict mode getting it closer up to the
stricter version in terms of the WTF parts of the language, but still leave
the fully dynamic and strict modes. Provided, ofc, that it is feasible,
though I would completely sunset non-strict mode at that point and leave
only one mode.

This essentially gives about a 10-year timeline of messaging, depreciation
and warnings to everyone. And at that point, if someone still did not do
anything to fix up things - well, I'm sorry, but it's your problem then to
figure out. I have done a few major 5 to 7 upgrades, one of them was an
especially bad case of PHP 5.1 to 7.1 cause it relied on PHP 4 behaviours
that were deprecated with PHP 5.0 and 5.1 and fatal error in 7 - it is not
as bad as many people think.

>

--000000000000eea74e059195c84f--