[wp-trac] [WordPress Trac] #38323: Reconsider $object_subtype handling in `register_meta()`

[WordPress Trac]

#38323: Reconsider $object_subtype handling in `register_meta()`
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Options, Meta APIs                   |  Review
 Severity:  normal                               |     Version:
 Keywords:  has-patch needs-unit-tests 2nd-      |  Resolution:
  opinion                                        |     Focuses:  rest-api
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:22 jnylen0]:
 > Some discussion in Slack today:
 https://wordpress.slack.com/archives/C02RQBWTW/p1491423937985603
 >
 > The solution I like the best so far is the introduction of a new
 `WP_Object_Type` class (perhaps not the best name).  This class would be a
 very simple pointer to one or more object types for which the meta key
 should be registered.
 >
 > Then, `register_meta` could be updated to accept one of these objects as
 its first parameter, filling in the gap in functionality discussed in this
 ticket.

 +1
 >
 > It was proposed to make `WP_Object_Type` a base class for `WP_Post_Type`
 and `WP_Taxonomy`.  I disagree with this because the proposed class is
 '''not''' an object type itself, rather it is a '''pointer''' to one '''or
 more''' object types.  Having a `WP_Object_Type` that can represent "all
 post types" is necessary, but it would break this encapsulation.

 I don't think this is a limitation. I think it makes sense to have
 `WP_Object_Type` as a non-abstract class that represents an object type.
 The `WP_Post_Type` and `WP_Taxonomy` (and other future subtype) classes
 can inherit that class and provide data to make them a representation of a
 subtype (as that's what they are). We have a chance to create a common
 ground for those classes, and I don't think it makes sense to add another
 standalone-class without integration that actually contains related
 functionality. Another advantage would be that you get the object subtype
 back when registering it (for example `$post_type = register_post_type(
 ... )`) so that you could then immediately `register_meta()` for that
 subtype.

 [attachment:wp-object-type.diff] is a quick example of what I have in
 mind. Maybe it would even be more accurate to introduce a `WP_Subtype`
 class and inherit `WP_Object_Type`, and then `WP_Post_Type` and
 `WP_Taxonomy` could inherit `WP_Subtype`.

 (Please not that all these names are probably not the best, the
 implementation is what we should focus on for now.)

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