Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116334
MIME-Version: 1.0
References: <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
In-Reply-To: <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
Date: Fri, 12 Nov 2021 12:59:42 -0600
Message-ID: <CAJp_myU5Wc3heD0vB7P8a65x4zd2pBmh9jt8Jb38SP80Kz0JSQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007d5ab105d09c1002"
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--0000000000007d5ab105d09c1002
Content-Type: text/plain; charset="UTF-8"

I recognize it's a bit late to be commenting, now that voting has
started... but this feels like a solution for which we already have
workable solutions, and which will instead lead to a lot of
misunderstanding and breakage in the user ecosystem.

Our IDEs, coding standards, and static analysis tools can already flag
these things for us, helping us catch them early. Hell, unit testing will
find these for us, when a test fails due to a value not being set in a
property that we expected.

Making this fundamental change to the language means, however, that a lot
of things that we were previously able to do that "just worked" now raise a
deprecation notice, and, later, a compilation error... unless we make a
change to our already working, fully functional code.

I think the Locked Classes approach made far more sense here, because it
didn't require changes to _working_ code. By making the behavior opt-in,
developers get to choose if that's what they want for their classes,
instead of having a backwards breaking change thrust on them.

(Perhaps an even better solution would be a declaration, like we have for
strict_types, which we could do per file.)

Or maybe I'm missing something else: was there something at the engine
level that was driving this, a significant performance gain we get from
changing the behavior? Because if there was, there was no discussion of it.
In fact, the only discussion of "why" in the RFC is "In modern code, this
is rarely done intentionally". Why is that justification for changing the
behavior? Can you quantify how much code would be affected by this change?
and how much would benefit?

Yes, I know that code I write would benefit from it, and personally I'd
love to have a way to opt-in to something more strict - but I think a
switch like this is going to make upgrading to version 9 difficult if not
impossible for a huge number of PHP users.

Sweeping changes like this need data behind them. If there's such data for
this RFC, it's not present in the proposal, and as such, I cannot
understand what drives it.

On Fri, Nov 12, 2021 at 7:08 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>


-- 
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

--0000000000007d5ab105d09c1002--