Differences

This shows you the differences between two versions of the page.

--- rfc:locked-classes [2019/03/11 11:03] – Fix formatting in reflection section nikic
+++ rfc:locked-classes [2019/06/04 18:56] (current) – Withdrawn imsop
@@ Line 3: / Line 3: @@
   * Date: 2019-03-10
   * Author: Rowan Collins [IMSoP], rowan.collins@gmail.com
-  * Status: Under Discussion
+  * Status: Withdrawn
   * First Published at: http://wiki.php.net/rfc/locked-classes
@@ Line 109: / Line 109: @@
 A pull request containing an initial implementation with basic tests is available on github: https://github.com/php/php-src/pull/3931
-===== Implementation =====
+===== Reasons for Withdrawal =====
-TODO: After the project is implemented, this section should contain
-  - the version(s) it was merged into
-  - a link to the git commit(s)
-  - a link to the PHP manual entry for the feature
-  - a link to the language specification section (if any)
-===== References =====
+This RFC was discussed on the Internals list in March 2019. See archive here: https://externals.io/message/104620
-TODO
-===== Rejected Features =====
+While the reasoning behind the feature was welcomed, the general consensus was that it was not quite right in its current form.
-None yet
+Specific concerns raised included:
+  * The handling of ''%%__set%%'', ''%%__get%%'', and ''%%__unset%%'' on locked classes is unnecessarily complicated. Perhaps these should just be prohibited instead.
+  * The restriction on ''unset()'' prevents clearing of reference bindings set with ''$foo->bar =& $baz''. One possibility is to reset the property to ''null'', but not remove it from the list of properties on the object.
+  * Contrary to both of the above suggestions, there was interest in using locked classes with "lazy-loading", where properties are deliberately removed to trigger ''%%__unset%%''.
+  * The extra keyword was considered "ugly" by some. While subjective, this does point to a lack of long-term vision: if nearly all PHP classes should behave this way, requiring the boilerplate on each declaration is cumbersome.
+  * If the primary purpose is to prevent //accidental// use of dynamic properties, the flag would be better set where the object is //used// (e.g. with a ''declare()'' flag) rather than where it is //defined//. That way, use of third-party objects can be subject to strict checking without modifying shared code; and deliberate "trap doors" can be used to implement tricks that rely on dynamic properties.
+The feature proposed in this RFC was deliberately conservative to keep the implementation simple, and bring it to users as soon as possible. However, it may be sensible to revisit the idea in combination with other concepts, such as packages/namespace-scoped declares, and a roadmap for making strictness the default.

Differences

Page Tools