[wp-trac] [WordPress Trac] #60875: Handler proposal for known dynamic properties that are initialized and set late only when getting its value

WordPress Trac noreply at wordpress.org
Mon Apr 1 16:29:51 UTC 2024


#60875: Handler proposal for known dynamic properties that are initialized and set
late only when getting its value
-------------------------------+--------------------
 Reporter:  hellofromTonya     |      Owner:  (none)
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  6.6
Component:  General            |    Version:
 Severity:  normal             |   Keywords:  php82
  Focuses:  php-compatibility  |
-------------------------------+--------------------
 As noted in #56034:
 >Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2
 and are expected to become a fatal error in PHP 9.0, though this last part
 is not 100% certain yet.

 There are multiple instances of **''known''** dynamic properties that only
 get initialized and set when getting their value (i.e. which happens
 within the `__get()` magic method).

 For example:

 * `WP_Term`'s `data` (see
 [https://core.trac.wordpress.org/browser/branches/6.5/src/wp-includes
 /class-wp-term.php#L235 the code]). Tracked in #58087.
 * `WP_Block`'s `attributes`
 ([https://core.trac.wordpress.org/browser/branches/6.5/src/wp-includes
 /class-wp-block.php#L179 see the code]).

 While [54133] added `#[AllowDynamicProperties]` attribute to these
 classes, that strategy is specifically for ''unknown'' dynamic properties
 and not for known like the above examples.

 == Strategy

 These types of known dynamic properties were intentionally designed to get
 late / lazily initialized each time code gets the property's value. As
 this is by design, retaining it must be a priority to ensure not only BC
 but also to avoid breaking code that depends upon it.

 The strategy:
 * Retain the design of each property that is late / lazily initialized.
 * Declare the property on the class as either private or protected
 visibility.
 * Add `__isset()` magic method to ensure `isset()` works correctly (it
 does not right now). This step is needed for functions like
 `wp_list_pluck()` (see #59774).
 * Add `__set()` and `__unset()` to have a full set of magic methods, but
 document both to indicate their behavior gets overwritten the next time
 getting the property's value.
 * Add `wp_trigger_error()` with `E_USER_DEPRECATED` to each of the magic
 methods for all unknown dynamic properties.

 See it in action:
 * How it works now https://3v4l.org/VGDNn
 * How the strategy will work https://3v4l.org/6gXXU

 This ticket is to:
 * layout the architectural strategy.
 * identify all Core classes with this type of dynamic property.
 * implement the strategy for each of instance.

 == References:

 * RFC: https://wiki.php.net/rfc/deprecate_dynamic_properties

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60875>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list