[wp-trac] [WordPress Trac] #27231: Tweak wp-db.php so running WordPress on HHVM doesn't require hacking the core

[WordPress Trac]

#27231: Tweak wp-db.php so running WordPress on HHVM doesn't require hacking the
core
-------------------------+------------------------------
 Reporter:  dave1010     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Database     |     Version:  3.8
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by nacin):

 I spoke about this with Sara Golemon of Facebook (the author of this post)
 at a conference last year. We were talking HHVM + WordPress and she
 mentioned this was the only remaining incompatibility. From what I recall
 it simply issued a notice of sorts in HHVM, versus preventing compilation.
 She was concerned WordPress required it, while after inspection it was
 clear this is now just for back compat. So, someone running HHVM +
 WordPress could simply ignore this issue.

 While it wouldn't be difficult for HHVM to support case-insensitive
 constants (https://github.com/facebook/hhvm/issues/129), it doesn't look
 like HHVM will do so. I don't exactly blame them; it's a pretty terrible
 concept.

 Anyway, when looking into this with Sara I had no idea we had this little
 artifact in WordPress. It dates to ezSQL (and still exists
 [https://github.com/jv2222/ezSQL/blob/master/shared/ez_sql_core.php#L18-L20
 "upstream"]) and somehow managed to be dropped from ARRAY_N and ARRAY_A in
 [1180]. It stayed for `OBJECT` for whatever reason.

 I think we have a few options here:
  1. Define `object` as `OBJECT` and do nothing else.
  2. Define `object` and `Object` as `OBJECT` and do nothing else.
  3.  Add support in get_results() and get_row() for `OBJECT` in a case-
 insensitive fashion, and also define `object` as `OBJECT`, thus making it
 so only `Object` or `ObJeCt` actually catches the fallback.
  4. Add support in get_results() and get_row() for `OBJECT` in a case-
 insensitive fashion and do nothing else.

 I could only find three non-`OBJECT` uses in the plugins directory, all of
 them being `object`:
 {{{
 plugins/author-profiles/author_widget.php:107:$comment_counts = (array)
 $wpdb->get_results("{$get_results}", object);
 plugins/cbpress/lib/class.cats.php:280:         $result =
 $wpdb->get_row($query,object);
 plugins/lemonnews/classes/class-lemon-news-model.php:102:
 return $wpdb->get_row( $sql, object );
 }}}

 `object` seems like it's not a big deal to support, but it's inconsistent
 with `ARRAY_A`, `ARRAY_N`, and `OBJECT_K`. And, `OBJECT` is the default in
 all cases it is used, so it's not like we benefit from more ways to
 specify it.

 I wouldn't mind removing this artifact. The attached patch,
 [attachment:27231.diff], implements point 3, though removing the `define(
 'object', 'OBJECT' )` also takes care of point 4.

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