Re: [PHP-DEV] [RFC] Deprecate dynamic properties

This is only part of a thread. view whole thread
  115871
August 26, 2021 22:10 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> The crux of the issue is what our end goal is: > > 1. Require users to explicitly annotate classes that use dynamic > properties, but otherwise keep dynamic properties as a fully supported part > of the core language. > 2. Remove support for dynamic properties entirely. The core language only > has declared properties and __get/__set, and nothing else. stdClass is just > a very efficient implementation of __get/__set.
I think goal (1) is reasonable for the long run, and goal (2) is taking it a bit too far for PHP. -- Stas Malyshev smalyshev@gmail.com
  115874
August 27, 2021 03:02 pierre.php@gmail.com (Pierre Joye)
Hi Stan,

On Fri, Aug 27, 2021 at 5:10 AM Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > Hi! > > > The crux of the issue is what our end goal is: > > > > 1. Require users to explicitly annotate classes that use dynamic > > properties, but otherwise keep dynamic properties as a fully supported part > > of the core language. > > 2. Remove support for dynamic properties entirely. The core language only > > has declared properties and __get/__set, and nothing else. stdClass is just > > a very efficient implementation of __get/__set. > > I think goal (1) is reasonable for the long run, and goal (2) is taking > it a bit too far for PHP.
I feel the same way. However my gut feeling tells me that we will end up with (2) sooner or later. Having StdClass behaving differently (even if it is technically not, I don't think the "it is a more efficient get/set implementation" will make it through our users base) looks inconsistent. 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. Best, -- Pierre @pierrejoye | http://www.libgd.org
  115875
August 27, 2021 03:56 tobias.nyholm@gmail.com (Tobias Nyholm)
Just giving my 2 cents: 

> 2. Remove support for dynamic properties entirely.
I support this RFC and I like the end goal to be to remove the dynamic properties entirely. Dynamic properties are just confusing for beginners. “This is how you declare properties, the scope, the type, name etc.. but you don’t have too…” I also remember that I’ve fixed more than one bug because I misspelled a property name. I understand there will be an impact on legacy code but there is help to find dynamic properties (static analysers) and there is also a clear upgrade path. // Tobias
  115876
August 27, 2021 05:19 mike@newclarity.net (Mike Schinkel)
> On Aug 26, 2021, at 11:02 PM, Pierre Joye php@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