Re: [VOTE] Deprecate dynamic properties
| From: | Dan Ackroyd | Date: | Thu, 25 Nov 2021 20:58:26 +0000 |
| Subject: | Re: [VOTE] Deprecate dynamic properties | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116516@lists.php.net to get a copy of this message | ||
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