RFC: Locked Classes

Hi Rowan, Overall good idea, except that I disagree with the `unset()` being disabled: that bit is strictly required for lazy-loading purposes, and mostly harmless for userland ("normal" people don't do it, libraries do it). Besides that (blocker for me), if this RFC would be enforced in my coding standards of choice 👍 Does anybody know if this has potential for engine optimizations? On Sun, 10 Mar 2019, 19:35 Rowan Collins, <rowan.collins@gmail.com> wrote:

Isn’t unset() currently only way to remove reference? This part is hence very problematic.

Nice. This would help enforce at least one element of immutability in userland; namely, not having to define `final public function __set()` and `final public function __unset()` to prevent adding and mutating undefined properties.

On Sun, 10 Mar 2019 at 18:35, Rowan Collins <rowan.collins@gmail.com> wrote:

I believe those two parts of the RFC are completely possible already in user-land with a trait similar to the one below. What would be the compelling case for making it be a keyword, rather than the user-land implementation that is already achievable? Also.....this seems to be a special case of an idea that has come up repeatedly, of allowing the concept of 'packages' with rules applied to all of the classes in a package e.g. * class Friendship which only allows access to certain methods to other classes in the same package. * strict enabled by default for a classes in a package. and now this RFC (or at least 2/3 of it) could be implemented by adding some traits by default to all classes in a package. Rather than adding a special case, I'd much rather we looked at providing the general case. cheers Dan Ack trait LockedClass { public function __set($name, $value) { throw new \Exception("Property [$name] doesn't exist for class [" . get_class($this) . "] so can't set it"); } public function __get($name) { throw new \Exception("Property [$name] doesn't exist for class [" . get_class($this) . "] so can't get it"); } }

On Sun, Mar 10, 2019 at 7:35 PM Rowan Collins <rowan.collins@gmail.com> wrote:

I like the general idea of this, though I think it's not quite the right way to go about solving the problem. The issue I see with this proposal is that it requires annotating each class with an additional keyword -- however, chances are good that people will want all *classes* to be locked, including those they do not have direct control over (coming from libraries). The solution I would prefer is the ability to declare that within a project, all interactions with objects (whether they are my own or come from 3rd parties) should disallow the creation of dynamic properties. This differs from your proposal in two important points: 1. You cannot create dynamic properties on objects even if they come from 3rd-party code you do not control. 2. 3rd-party code may interact with your objects (and it's own) however it likes. It is not affected by the disabling of dynamic properties in your project code. If this sounds familiar, this is basically strict_types, but for dynamic properties. Of course, doing this with declares as they are is rather cumbersome, because you'd have to specify them in every single file. Things would be different if you could specify a declare for a whole project... This is what https://wiki.php.net/rfc/namespace_scoped_declares was about, and it actually happens to use exactly this example as one of the things the mechanism could be used for. I still think that this would be the more principled approach to this issue, especially as it easily extends to other problem areas, without requiring a new keyword for each. (Based on previous feedback, it should probably be directory-scope declares rather than namespace-scope.) Now, to get back to your RFC, two notes: 1. The BC break section is not terribly clear due to the use of "semi-reserved". I initially assumed that this was a contextual keyword (i.e. only has special meaning immediately before "class") but apparently this is a normal reserved keyword in the implementation (i.e. no classes, functions, namespaces etc named "locked"). 2. It is possible to break a reference by reassigning it to another reference, like so: $null = null; $this->prop =& $null; unset($null); This is not quite as good as unsetting because it leaves behind an rc=1 reference, but that would be the way to remove a reference without unset(). Regards, Nikita

Hi!

Isn't it just: trait Locked { public function __set($name, $value) { throw new RuntimeException("Property $name not declared!"); } public function __get($name) { throw new RuntimeException("Property $name not declared!"); } public function __unset($name) { throw new RuntimeException("Property $name not declared!"); } } The RFC says: While this can be achieved through strategic use of the __set, __get, and __unset magic methods, this is long-winded, hard to optimise, and interferes with other uses of those methods. I don't see how it's "long-winded" - it's just three one-liners, I don't see how "interferes with other uses" of these methods (if you want other uses, just add code to the method), and as for optimization, I think we already have optimization for pre-declared properties, and if you don't use any others, it would work just as well.