[wp-trac] [WordPress Trac] #35658: Provide additional data for registered meta through register_meta()

[WordPress Trac]

#35658: Provide additional data for registered meta through register_meta()
-------------------------------------------------+-------------------------
 Reporter:  jeremyfelt                           |       Owner:  jeremyfelt
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  4.6
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests needs-testing has-  |     Focuses:
  patch rest-api                                 |
-------------------------------------------------+-------------------------

Comment (by MikeSchinkel):

 Replying to [comment:65 jtsternberg]:

 > Mike, I like your patch, but there does seem to be some opinionated
 stuff in the WP_Object_Type class (like all the `$_short_types` related
 business) that may be overkill for getting an MVP in to core.

 Cool.

 The class I included was a hastily prepared copy of code we are using as a
 base for our projects. Hastily because I saw this ticket moving quickly
 and did not want to miss the chance to weigh in before a decision was
 made.

 Clearly to make it into core the class will need to be massaged by
 committee so I assumed that if the idea was accepted my code would get
 changed quite a bit.

 The short_type stuff can be pulled out no problem, it was just critical to
 an object relationships module we built, but if this made it into core I
 could easily put that code elsewhere.

 > I'm also curious if we really '''need''' to support all the different
 methods for instantiation. Seems it would be prudent to limit that to a
 specific set like either a colon-separated string or array with `'type'`
 and `'subtype`' keys.

 We did this  so that we could have flexibility, especially related to
 being able to use [https://en.wikipedia.org/wiki/Structural_type_system
 Structural Typing] ''(allowing other objects to be passed in  `->type` and
 `->subtype` properties and still have them work.)''   But ultimately none
 of that is needed, it could just accept no more than either a string or an
 existing `WP_Object_Type` instance.

 > Also, can we pretty please NOT do `final` on the class? (Mike, I know
 you're likely doing that to mirror existing core classes, but I'm hoping
 we can avoid it anyway). For instance, what if I wanted to extend this
 class for use in CMB2? Well.. I couldn't.

 Funny, I am usually extremely frustrated when core uses `final`, but in
 this case I felt it was warranted because IMO an `WP_Object_Type` would
 effectively become a new standard data type and so locking it down and
 standardizing it made the most sense to me.

 That said, '''the only parts I feel really strong about are''':

 1. Having a class that encapsulates a major type and a minor type
 2. That can be instantiated by either a string or an existing instance of
 the same class, and
 3. That can be cast back to a string to the form "{type}:{sub_type}".

 Anything else about it can be changed without harming the concept.

 And If we could get this I think it would be a huge win for core, and
 given my experience with it I think everyone will be surprised at how
 often they discover it can simplify other code as time moves forward.

 > Also, nit-picky, but would prefer `is_type_*` methods over `is_*_type`
 so as to avoid confusion with `is_post_type`.

 Like I said, I only really care about 1., 2. and 3. above.    So whatever
 the consensus is.  :-)

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