[wp-trac] [WordPress Trac] #55942: Add a "value type" parameter to get_option() and get_metadata()

[WordPress Trac]

#55942: Add a "value type" parameter to get_option() and get_metadata()
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  6.3
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------

Comment (by knutsp):

 Replying to [comment:63 azaozz]:
 > Replying to [comment:62 knutsp]:
 > > What will be the difference to writing...
 > > What will be the difference to writing
 > > (string) get_option( 'my_option' );
 > > (bool) get_option( 'my_option' );
 > > (int) get_option( 'my_option' );
 > > as we do now?
 >
 > No much difference, just a bit cleaner way to write it.

 Cleaner that common, plain PHP, by adding an extra argument to make the
 function convert types?

 > > If the saved type is still to be guessed...
 >
 > It's not "to be guessed", rather it is to get a value with an expected
 (strict) type.

 If not centrally registered, not in the database, it's guessing what the
 type was (intended to be) before saving.

 > Adding this param would make it easier to fix that, and it also reduces
 calls to maybe_unserialize() a little.

 To convert an unkown type of data to fit in a (strictly) typed property is
 trivial, at least when working with supported PHP versions, as
 demonstrated above. To do it correctly, as the entity that saved the data
 in the first place, need the type to be centrally registered or saved
 along with the data in the database. To handle maybe serialized
 array/object without sniffing will require data with structural types that
 need serialization to be registered centrally or stored in database, as
 far as I can see.

 A refined `register_setting`/`register_meta` or two new, simpler
 `register_setting_type`/`register_meta_type` that work in some logical
 connection with each other, could be a way forward.

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