[wp-trac] [WordPress Trac] #47699: Remove redundant JSON polyfills for PHP native functionality

[WordPress Trac]

#47699: Remove redundant JSON polyfills for PHP native functionality
-------------------------------------------------+-------------------------
 Reporter:  jrf                                  |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion has-unit-      |     Focuses:  coding-
  tests                                          |  standards
-------------------------------------------------+-------------------------

Comment (by Clorith):

 I think we may need data to back this, as a discussion in this took place
 in March in the #core-php channel, and although it's compiled into PHP by
 default, many choose to define extensions manually when building PHP, and
 as such may not be including it.

 @SergeyBiryukov brought up the point that hosts did (and some still might)
 compile without the json extension. Given how important json is in the
 majority of interactions on the internet today, it would be beneficial to
 have some metric behind removing various polyfills, jsut so we don't
 "breaking the internet" by removing one (at least that was the outcome of
 the discussions back then).

 I see we've previously reached out to VaultPress for these kind of
 metrics, is this a viable approach still, or are there better ways to get
 anonymous data of that variety (I know there's been talk of it being
 useful in other scenarios, but we don't have anything like this our selves
 at times time last I heard).

 Related: #18015, #19524 (the removal of the polyfill when the minimum PHP
 requirement was bumped to 5.2 for WordPress 3.2)

 The percentages are likely different now (I would hope), but it would be
 nice to have confirmation on that if at all possible.

 ---

 Perhaps a golden middle ground could be taken in this instance, one where
 we deprecate the polyfills for 1-2 major core releases, where we implement
 a `_doing_it_wrong` when the polyfills that should be safe to remove are
 used. This should give ample warning in scenarios where they are used,
 while also covering our backs in the process?

 In fact, I think a deprecation route such as this would be beneficial for
 any polyfill slated for removal.

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