Isn’t unset() currently only way to remove reference? This part is hence very problematic.
> On 10. Mar 2019, at 19:35, Rowan Collins <rowan.coll...@gmail.com> wrote: > > Hi all, > > I'd like to present a new RFC for "locked classes": classes which restrict > dynamically adding or removing properties from their instances. > > While it can be useful, the ability to set an object property which is not > part of the class definition can also lead to subtle bugs. Banning this for > all objects would be a significant and painful breaking change, so I propose > instead the option to mark a particular class with a new keyword, "locked". > > An instance of a locked class behaves like any other object, except that: > > - Attempting to set a property on the instance which was not declared in the > class (or inherited from one of its parent classes) will throw an error, and > the instance will not be modified. > - Attempting to read a property on the instance which was not declared (or > inherited) will throw an error, rather than raising a Notice and evaluating > to null. > - Attempting to call unset() on any property of the instance will throw an > error, and the instance will not be modified. > > Note that ECMAScript / JavaScript includes a similar feature, called "sealed > objects". However, the proposed modifier applies to classes, and "sealed > class" has a different meaning elsewhere (e.g. C#, Kotlin), so I've chosen > "locked class" to avoid confusion. > > For further details and examples, please check the RFC at > https://wiki.php.net/rfc/locked-classes and the tests in the draft > implementation at https://github.com/php/php-src/pull/3931 > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
