On Sun, Jun 6, 2021 at 12:14 AM tyson andre <tysonandre...@hotmail.com> wrote:
> Hi Kamil, > > > I have reworked the RFC based on some feedback. The improved RFC now will > > hold 2 votes. One vote to decide whether the behaviour should be > deprecated > > from false, and another from null. > > > > If there are no objections then I would like to start the votes in a > couple > > of days. > > > > However, I would still like to hear from you whether you > > use autovivification from false and/or null in your projects. So far, I > was > > not able to identify when this would be useful in real-life scenarios. > > > > RFC: https://wiki.php.net/rfc/autovivification_false > > Without an implementation it'd be hard to actually tell what the impact > would be. There isn't one linked to from the RFC or on > github.com/php/php-src. > You might have code in your application or external dependencies that > relies on that without you remembering or being aware of it for null. > > **I started working on a prototype independently just to get an idea of > how many things would encounter deprecations. See > https://github.com/TysonAndre/php-src/pull/17** (I am not one of the > RFC's authors. If someone bases their implementation on that prototype PR > please keep the authorship of initial commits (e.g. `Co-Authored-By` in git) > > Also, what is the planned deprecation message, what about documenting all > kinds of expressions that can cause autovivication, etc: e.g. `$x = > &$falseVar['offset']` > > > My assumption is that false would be reasonably practical to implement > (this patch with `== IS_FALSE` instead of `>= IS_NULL`, plus some changes > to the optimizer to account for the fact some dimension assignment > statements might now have. > For IS_NULL, that would probably require more familiarity with php's > internals than I have to be certain the implementation is correct and to > properly distinguish between undefined and null when automatically creating > properties. > This is a good point. After a cursory look, it's not obvious to me how we could distinguish these cases. We do need to perform the null initialization here, as we can't just leave behind an undef element in the property table. I think it would be best to limit this proposal to the false case only. A way to put this is that auto-vivification only happens for !isset(), which is precisely undef or null, but not false. (The historical behavior was that it happens for empty(), which has been cut down over time to the point that false is the only other accepted value, at which point this framing doesn't make sense anymore.) Regards, Nikita
