Changes between Initial Version and Version 1 of Ticket #12955, comment 67
- Timestamp:
- 03/26/2018 03:15:39 AM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #12955, comment 67
initial v1 6 6 While I would be ecstatic to see this ticket moved forward. changing the object class would be 3 steps forward and then 2 steps back. It would create broken code if any classes are used statefully, e.g. if you assign value to properties and expect those values to be retained later in the code. It could result in a lot of memory thrashing; creating new objects based on existing objects every time a template tag used `get_post()` to sanitize a post. AND, it is not compossible; what if two different plugins want to change the post type to their own post custom type? Only one plugin would get to win. 7 7 8 '''As I think about it maybe the answer to this use-case need is not to filter get_postand not to remove `final` but instead''' to extend `WP_Post` with magic methods and filters. Add `__call()` `__set()` and Add filters that can affect both those as well as `__get()`. Add an action hook in `__construct()` and add a property array `supports` that allows plugins to attach support (by array key) to posts and their own instances to implement the support.8 '''As I think about it maybe the answer to this use-case need is not to filter `get_post()` and not to remove `final` but instead''' to extend `WP_Post` with magic methods and filters. Add `__call()` `__set()` and Add filters that can affect both those as well as `__get()`. Add an action hook in `__construct()` and add a property array `supports` that allows plugins to attach support (by array key) to posts and their own instances to implement the support. 9 9 10 10 This would be much more compossible across plugins and would still allow plugins to ''"decorate"'' posts with properties and behaviors.