Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116516
MIME-Version: 1.0
References: <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
 <CAJp_myU5Wc3heD0vB7P8a65x4zd2pBmh9jt8Jb38SP80Kz0JSQ@mail.gmail.com>
In-Reply-To: <CAJp_myU5Wc3heD0vB7P8a65x4zd2pBmh9jt8Jb38SP80Kz0JSQ@mail.gmail.com>
Date: Thu, 25 Nov 2021 20:58:26 +0000
Message-ID: <CA+kxMuT5Wm7=EEandOYxpJeP1mX2b+qtJpzWuiZGJrxs92w9Vw@mail.gmail.com>
To: "Matthew Weier O'Phinney" <mweierophinney@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Andreas Heigl <andreas@heigl.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: Danack@basereality.com (Dan Ackroyd)

On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney
<mweierophinney@gmail.com> wrote:
>
> 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.

New users don't have these tools. And a lot of 'experienced'
developers don't have those tools either. A disconcerting number of
developers don't even use source control.

Although exactly which users a language should be designed to cater
for, I don't think an answer of "those who have used it long enough to
setup static analysis tools" is a great one.

But even when people have static analysis tools setup, they are slow to run.

Andreas Heigl wrote:
> So while the static analysis is one possibility, the other
> one is writing appropriate tests.
> .....
> So the mistakes-part would be easy to handle.

This is not my experience.

My experience is the same as Matthew Brown wrote:
> I have heard newcomers express literal
> surprise when discovering this for the first time, and not in a delighted
> way.

People encounter the 'feature' of PHP not warning or erroring on
dynamically creating a property by accident most of the time.

They make a typo in their code and wonder why their code isn't working
as expected.

Even though I use an IDE, and have pretty comprehensive static
analysis and tests, this feature keeps biting me often enough that I
created a trait to stop it
(https://github.com/Danack/Params/blob/main/lib/Params/SafeAccess.php)
which I normally copy and paste into each project.

Matthew Weier O'Phinney wrote:
> 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.

This is the trade-off that all RFCs that have BC breaks have:

1. it's going to cause some work for projects that deliberately use
this feature.

2. it's going to save time/improve the developer experience for people
in the future

If PHP was a dead language that fewer people are starting to learn,
and few new projects are started using it, then option 1 is probably
the side to prioritise. But I'm hoping that PHP isn't a dead language,
and that the future benefit from not having to spend so long debugging
their code is greater than a small amount of BC break.

For the people who are currently voting 'no', I'd ask are you really
sure that the amount of work adding "#[AllowDynamicProperties]" to the
classes you want to keep having dynamic properties is really that much
time compared to the time that would be saved by having PHP itself
give an error when a user accidentally creates a dynamic property?

cheers
Dan
Ack