On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney <mweierophin...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
