> On Aug 26, 2021, at 11:02 PM, Pierre Joye <pierre....@gmail.com> wrote: > I don't know how others feel about it, I think most want to go the > path to (2) and a more strict, if not almost fully strict PHP. Core > devs to simplify the engine, users to allow them easier checks and > safety in their frameworks or libs. End user don't really bother as > far as I can see. We may have to decide once the long term vision for > PHP and then do the changes accordingly, and more importantly, with > consistency.
I tend to concur that path (2) would provide the better outcome. However, eliminating dynamic variables would be eliminating the ability to simulate a(t least one) language feature that some (many?) people have been using dynamic variables to simulate. Maybe as part of deprecation of dynamic variables we should also consider adding this(ese) feature(s) to the PHP language? There are two approaches I can envision, Both would better enable the S.O.L.I.D. "open-closed" principle in PHP. 1.) Allow PHP class declaration across multiple files — A use-case for this is what I think is effectively the command dispatcher pattern where properties contain instances of classes that might be contributed by 3rd party code to allow those developers to access the instances by named property: e.g. $cms->map->display() where $map is added by a 3rd party library to the class for the $cms instance before $cms is instantiated. See: https://gist.github.com/mikeschinkel/ed4f9594c105dae7371bfce413399948 Some might view this as "monkey patching" but I view it as a more structured approach, like C# partial classes. 2.) Allow trait usage for a class from another file — This is just a slightly different spin on #1. See: https://gist.github.com/mikeschinkel/5b433532dc54adf53f5b239c8086fd63 Each approach has its own pros and cons but it probably depends on which would be easier and more performant to implement. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
