[wp-trac] [WordPress Trac] #22704: Automatic Core Updates

WordPress Trac noreply at wordpress.org
Sat Sep 28 18:04:01 UTC 2013


#22704: Automatic Core Updates
-----------------------------+-----------------------
 Reporter:  pento            |       Owner:  pento
     Type:  task (blessed)   |      Status:  assigned
 Priority:  normal           |   Milestone:  3.7
Component:  Upgrade/Install  |     Version:  3.5
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+-----------------------

Comment (by MikeSchinkel):

 Replying to [comment:79 wonderboymusic]:
 > Your example would still produce strict errors/warnings if you used
 `$this` in the methods hooked with `__CLASS__`

 Ah yes, thanks. Serves me right for not doing exhaustive testing for
 posting. I've revised the example to be what I had intended:

 - https://gist.github.com/mikeschinkel/6739395

 And the problem with just using a single class like your `Burrito` is
 unfortunately PHP does not allow same-named methods to exist both as
 static and as instance methods so you either get the ability to do
 something like `Burrito::add_salsa()` or you want to use singletons have
 to do something like one of the following:

 {{{
 global $burrito;
 $burrito::add_salsa();
 // or
 $GLOBALS['burrito']::add_salsa();
 // or
 Burrito:: get_instance()->add_salsa();
 }}}

 I would think none of those are ''"clean"'' enough for a core API.

 Also, if you are going to use your class for both hooking actions and/or
 filters and as an instance class in it's own right then you get into messy
 business because adding hooks in the `__construct()` method is no longer
 appropriate.  At that point you are relegated to using `static` methods
 for your hooks ''(which I think you were trying to avoid?)'' or you are
 going to have to concoct a really elaborate code pattern to allow
 instances for hooks and for, ahem, instances.

 As a side note, I've always disliked instantiation inside `get_instance()`
 if the class is always going to be loaded, i.e. if it hooks WordPress
 actions or filters.  Here's how I might rewrite if I were ignoring the
 other issues I surfaced:

 {{{
 class Burrito {
     /*
       * Private because we don't need to allow direct acccess.
       * Underscore to indicate it's not public
       */
     private static $_instance;

     static function on_load() {
        /*
         * Call like this and you know your hooks are hooked.
         */
        self::$_instance = new self;
     }

     private function __construct() {
        add_action( 'init', array( $this, 'add_onions' ) );
     }

     static function get_instance() {
        /*
         * No need to check for instantiation _every_ access.
         */
        return self::$_instance;
     }

     function add_onions() {
        // smelly business, really.
     }
 }
 Burrito::on_load();
 }}}

--
Ticket URL: <http://core.trac.wordpress.org/ticket/22704#comment:80>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list