On 12.11.2021 at 23:34, Matthew Weier O'Phinney wrote: > On Fri, Nov 12, 2021, 3:41 PM Larry Garfield <la...@garfieldtech.com> wrote: > >> The original version of the RFC would have (as of v9) allowed for the >> removal of some fugly code in property handling, resulting in engine >> improvements and some minor performance benefits. That was because it >> pushed the opt-in mechanism to "only if you extend stdclass", and stdclass >> would effectively have a trait with stock __get/__set implementations to >> handle dynamic property behavior. (It wasn't quite that, but effectively >> that's what it would do.) So that was the original impetus. > > None of that information was in the RFC. That sort of thing really needs to > be included, as it helps a ton in justifying changes of this nature. As I > noted, on reading it, the only rationale made is a quick mention that they > lead to programming errors, and even then, there's no detail really if > _how_.
At some point, the RFC explained some of the internal implications: <https://wiki.php.net/rfc/deprecate_dynamic_properties?rev=1629900759#internal_impact>. To give one example: <https://3v4l.org/f8OZj>; no that's not a memory leak, but rather the effects of materializing the properties HashTable. However, since the attribute solution, which already was a compromise to mitigate the BC break wouldn't make it possible to drop zend_object.properties and friends, this reasoning was removed. I still hope that we can get rid of this ugly stuff eventually. Obviously, that requires to educate people and to push code bases "softly". Offering an opt-out of dynamic properties or some switch to disable the deprecation would not help in that regard. That "leading to programming errors" is about userland code. Mistyping the property name might not even be noticed during development/QA, but may cause serious issues in production. Of course, a static analyzer would report this issue, but there is code where you'd have a hard time to get PHPStan level 0 or Psalm level 8 working (and baseline wouldn't catch existing issues). Oh, and well, we're actually talking about code which is not statically analyzed (or only at a very low level) anyway, don't we? > I'd like for a discussion on how we can allow the language to develop > without requiring yearly churn and burden on the surrounding ecosystem. And > just waving your hands and saying deprecations aren't errors is not an > answer - if it makes its way to an error log or is reported inline in a > page or in CLI output, it's an error. I'd argue that it is not. There are different levels of errors, and you should likely treat them as such. An error or exception is more severe than a warning, a warning is more severe than a notice, and a deprecation is yet different again. You can ignore the latter, if you don't care about the next PHP major yet; you can actually exclude them from any kind of error reporting, until you care enough about them to resolve them. Even libraries could add a "suspended" ("won't fix *now*") label to respective bug reports (and re-open when the time has come). Anyhow, I'm fully aware that PHP is pushing for years now. As far as I know, COBOL did not. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
