Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119870
MIME-Version: 1.0
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de> <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
In-Reply-To: <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
Date: Mon, 10 Apr 2023 15:29:58 -0300
Message-ID: <CADK1yXLie-hPJwKSUqpBgpOkWPBrBvcaXdFfLKxDMPbcT=1dYA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Stephan Soller <stephan.soller@helionweb.de>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009ad87b05f8ff9057"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: deleugyn@gmail.com (Deleu)

--0000000000009ad87b05f8ff9057
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 10, 2023, 1:17 PM Pierre Joye <pierre.php@gmail.com> wrote:

> hello,
>
>
> On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <stephan.soller@helionweb.de>
> wrote:
>
> > Hello,
> >
> > I'm sorry if this isn't the correct mailing list for that discussion but
> I
> > couldn't find a more appropriate one where people actually know how the
> > wind is
> > blowing.
> >
> > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
> > deprecations and fatal errors spooked me a bit (details below if you're
> > interested). That got me wondering about the long-term stability of PHP
> > (as in
> > language and API breaks) and I looked at the RFCs. I got the impression
> > that
> > static typing has a lot of traction now and I have no idea of what the
> > fallout
> > might be of changing a dynamically typed language into a statically
> > typed one.
>
>
> I keep reading this in multiple languages, pr even more frameworks.
>
> I understand agency work, managers pushing new features instead of a
> cleaning some legacy.
>
> however years of ignoring deprecation notices (very few were introduced
> right before 8.0).
>
> Most of them could have been fixed within a couple of hours in any code
> base, if they had tests.
>
> I would suggest, very very nicely, to review and rethink the development
> flows of these projects instead of asking php to freeze.
>
> best,
> Pierre
>

I resent the sentiment of "if your code or development process was exactly
like mine you wouldn't be here complaining" and I believe nobody is asking
PHP to freeze. Not everyone has the ability to fix every deprecation within
a couple of hours and not everyone has tests. Yes, we get it, it's common
knowledge nowadays that code without test is unmanageable, but if you
inherited a 15 year old codebase developed by multiple developers in a
start-up mentality producing code faster than they could actually plan for
and with no tests, its going to take some time to clean that up and if I
take longer than you would, does it mean I matter less as a PHP user?

PHP 8 is pretty great to work with and a lot better than previous versions,
but there was no opt-in aspect to a lot of PHP breakages. All that we're
asking here is for a bit more forgiveness to existing code that was
developed 2 decades ago by a complete different generation and still need
to run today while we clean it up.

>

--0000000000009ad87b05f8ff9057--