[wp-trac] [WordPress Trac] #24672: Remove final from WP_Post class

[WordPress Trac]

#24672: Remove final from WP_Post class
-------------------------------+------------------------------
 Reporter:  carlalexander      |       Owner:  (none)
     Type:  enhancement        |      Status:  reopened
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  3.5
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion        |     Focuses:
-------------------------------+------------------------------

Comment (by MikeSchinkel):

 Replying to [comment:25 Andy Schmidt]:
 > The possibility of an ill-behaved plug-in interfering with another plug-
 in already exists today with the "posts_pre_query" hook, and always does
 so in many other hooks.

 Yes. But using hooks it is possible for a site developer to fix the
 incompatibility without having to resort to modifying either plugin.

 If two plugins both inherit from `WP_Post` you can use the enhancements
 from either child class but you cannot use both since PHP does not support
 multiple inheritance.

 I guess you could create a 3rd class that could contain both of those
 instances and delegate, but that would only work for methods or properties
 that don't exist, not for ones that do, and PHP does not allow you to
 fully simulate a contained class in the container, for example
 `method_exists()` and `property_exists()` will return `false` for
 virtualized methods and properties.

 > then it doesn't matter if the so discarded post instances had been
 created by the native WP_Post class or any subclass thereof?

 Unless there are hooks like `'save_post'` that expect the post instances
 to have the additional methods and properties added by its plugin's child
 class.

 >  then it would do so after narrowly defining the case in which this
 occurs.

 What ensures that it would only do so narrowly?

 > the only thing that matters is that they will be recognized as "instance
 of" WP_Post throughout the subsequent core code.

 This is an op-ed aside, but interesting in other areas of computing there
 has been a recognition that logic based on identity is much more fragile
 than logic based on attributes and behavior.  For example, most of us know
 it is better in JS to test browsers for behavior than to maintain a list
 of browsers that are compatible.  But in PHP it seems people still think
 "instance of" is a good solution.

 A better solution would be for `WP_Post` to use the `'supports'` attribute
 passed in during `register_post_type` to determine if a post has a
 specific _"supports"_ value.  ''(This is basically dynamic interfaces.)''

 Along these lines #43740 proposes to add a `'wp_post_supports_instance '`
 hook to allow a plugin to add a contained class to each instance of
 `WP_Post` to contain custom functionality.

 > If developers add methods or properties, it is their responsibility to
 choose member names for which there is a reasonable expectation that they
 are highly unique to avoid future name clashes.

 The problem is in a shared code ecosystem where ''"responsibilities"'' are
 not policed, such as the WordPress plugin repo, too many developers will
 use common names that **will** clash. So it is the responsibility of the
 core developers to guard against ''(likely unintentional)'' bad behavior.
 Hence `final`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/24672#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform