Make WordPress Core

Changes between Version 1 and Version 2 of Ticket #35658, comment 72


Ignore:
Timestamp:
06/30/2016 12:16:12 AM (8 years ago)
Author:
MikeSchinkel
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35658, comment 72

    v1 v2  
    88Understood.  Your comment as well as @jtsternberg's comment made me rethink the approach of the 35658.5.diff patch and was something I wanted to address for a long time, which is to create a `::get_instance()` ''"~factory"'' method and to make `WP_Object_Type` immutable.
    99
    10 '''Immutability means '''two(2)  things:''' lower overhead in terms of memory use''' when used frequently -- only the cost of aN object reference vs. the cost of a string references and alls its characters -- and it makes `WP_Object_Type` truly just a data typing mechanism which is effectively all I ever intended it to be.
     10'''Immutability means '''two(2)  things:''' lower overhead in terms of memory use''' when used frequently -- only the cost of an object reference vs. the cost of a string references and all its characters -- and it makes `WP_Object_Type` truly just a data typing mechanism which is effectively all I ever intended it to be.
    1111
    1212In addition your comment made me think through the naming of the major type that had always bothered me because of its inconsistency ''(i.e. `'post'`, `'term'`, `'user'` and `'comment'`.)''  The `->type` property that I used in the earlier patch was too generically named, and calling it `object_type` such as in 35658.8.diff would mean forcing the `object_type` name for the major type and thus ''(possibly)'' inadvertently standardizing on a new core notation for object type/subtype which as you said might create a problem for forward compatibility.