Re: RFC: Locked Classes

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.collins@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 >